CN101141455A - 一种网络资源与服务的统一描述方法 - Google Patents
一种网络资源与服务的统一描述方法 Download PDFInfo
- Publication number
- CN101141455A CN101141455A CNA2007101217491A CN200710121749A CN101141455A CN 101141455 A CN101141455 A CN 101141455A CN A2007101217491 A CNA2007101217491 A CN A2007101217491A CN 200710121749 A CN200710121749 A CN 200710121749A CN 101141455 A CN101141455 A CN 101141455A
- Authority
- CN
- China
- Prior art keywords
- service
- resource
- network
- inter
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
本发明提出一种网络资源与服务的统一描述方法,主要针对互联网的服务和资源的查找,提出以本体描述为基础,将资源和服务通过属性联系起来的统一描述方法,以实现对资源和服务的统一查找。本发明包括:包含局域网和广域网以及移动通讯网的互联网,其关键步骤是:定义本体的类的层次;定义属性;用户向注册中心注册其提供的资源和服务;用户端对网络资源进行查询。本发明将客户需要从网络上获得的网络资源和服务做了形式上的统一,基于这种统一可以实现资源和服务的注册和查询。其意义在于将现存的各种关联不大的注册和查询方法联系起来,用户可以在一个专用的资源和服务查询端对网络的所有事物进行更有效的查询,给用户提供了极大的便利。
Description
技术领域
本发明涉及一种网络资源与服务的统一描述方法,是一种电数字处理通讯方法,是一种计算机网络通讯技术。
背景技术
互联网是一个“网络的网络”,它把世界上的各种大大小小的网络汇聚在一起,推动了网络技术的迅速发展。在互联网发展初期,网站相对较少,网页数量亦较少,因而信息的查找对于人来说是一件轻松的事。然而伴随着互联网爆炸性的发展,普通网络用户已无法掌控这个信息的海洋。1994年,针对网页的搜索引擎蜘蛛程序的出现填补了这个空白,同年超级目录索引Yahoo拉开了第一代搜索的序幕。搜索引擎是一个信息处理系统,当今搜索引擎的主流是基于网络爬虫的第二代网络搜索引擎,主要涉及网络爬虫技术、索引技术、相关度及排序技术。当然,现在以Google为代表的多个搜索引擎正在不断扩充及完善他们的功能。
从搜索引擎的迅速发展可以看出,用户对从海量信息中准确地查找资源的要求非常迫切。当今的web时代,所有的网站分布式地支撑起了互联网的骨架,而搜索引擎是解决对网页信息查找的一个比较理想的办法。但是,如今的B/S(浏览器/服务器)模式并不能完全取代C/S(客户端/服务器)模式,互联网上还有很多的信息游离于web这个骨架之外,比如按其它网络协议开发的网络服务器和客户端。也就是说互联网上的很多资源和服务并没有列入搜索引擎的考察范围,可能要通过多次的URL的链接用户才能找到他想要的资源或服务。
为了解决这个问题,下一代网络中的一体化网络方案引入了分布式注册中心的概念。网络客户端将其可以提供的资源和服务注册到注册中心,其他客户想要查找时可以直接向注册中心查找自己需要的资源,各个注册中心采取对等网的方式相联。
在此方案中,注册中心要能为资源和服务归类,同时要对用户的查找给予准确、有效的响应,就必须采取一种有别于关键字匹配的方法。本发明采取语义的方法,对各种网络资源和服务建立一个统一的关联描述方法,在有了此领域本体后,我们可以对注册的资源和服务进行语义查找。语义查找有别于一般关键字的匹配查找方法,利用本体描述语言及其推理规则用户可以通过一些模糊的查询得到准确的信息。
现有资源的描述、注册和查找方案及缺陷:
互联网上的现有资源,如HTML文档、图像、视频片段、程序等,由URI(统一资源标识符)来标识,现在通常用于定位的字符串是URL(统一资源定位符)。其一般形式是:scheme://host:port/path?query#fragment,scheme表示协议,host表示主机名,port表示端口号,path表示在主机上的路径,query可选,在动态网页中可用来传递查询参数,fragment是信息片断,用于指定网络资源中的片断。
资源的表示方法确定以后,对于资源的注册和查找并没有统一的方法。因为虽然资源可以用统一标识符来表示,但资源和资源之间属性的差异很大。如一个HTML文档和一段视频的差别就很显著。现在的大部分资源都是以HTTP服务器上的URL链接形式出现的,可以看作是一种被动地注册,这个资源在等待它的URL被需要它的用户搜索到。还有以其它协议形式注册的资源,如FTP,BT,其发布大多数也需要通过HTML网页。
因为资源的注册形式很简单,有些甚至只是简单的发布到网上。所以对于资源的查找来说增加了难度。通常,用户需要经过多次URL链接才能找到所需的资源。搜索引擎就是在此背景下发展起来,并逐渐成为互联网查找资源的工具的,它主要基于关键字来进行查找。
现有服务的描述、注册和查找方案及缺陷:
现在互联网能提供的服务种类繁多,并且形式各不相同。如SIP电话、视频会议等,都会有自己的客户端和服务器。在提供服务的过程中,会遵循它们专用的协议,传输特定的内容。所以对于现在的网络来说,服务并没有统一的描述方式。
对于服务的注册,每种不同的服务都会有自己的注册方法,其方法应该在其协议中明确。注册的方法基本上可以分为两大类:第一类是有专门的注册服务器的注册方法;第二类是没有注册服务器的方法,如利用广播通告的方法。
服务的查找也是基于自己系统内部的注册方式而定的。有专门服务器的系统的服务查找是主动发现的查找方式,而没有专门服务器的系统通常采用被动查找方式,或结合HTML网页的查找方法。
在互联网上进行资源、服务的注册和查询的时候,因为资源和服务的关系没有明确的定义划分,通常通过人的辨识来判断,用户很难也没有必要自己去区分他需要的是一个资源还是一次服务,或者是两者混杂(如果包括服务的调用等后续过程,服务和资源的区别还是很明显)。例如一次SIP电话的通话,通常我们将其作为一次语音服务,但如果将其作为资源,通话端只需获得这个资源的一些参数(SIP电话号)即可以找到这次服务,这样我们也可以说建立连接的过程是一个搜索资源的过程(它并不涉及后面的通话过程)。另一个例子:webservices,其一次服务的注册和调用是一个紧密相连的过程,查询端通过查询得到的信息较多,一般在一个wsdl文档里,它不同于互联网的其他应用,一般的应用得到IP地址和端口号就可以建立连接,查询和调用的关联较弱,但web services查询和调用是一个整体。在此情况下,我们很难将web services服务的注册信息划为资源来进行单独查找。综上所述,我们迫切需要一种方案来完成对互联网资源和服务的统一描述,以方便其注册和查询。
发明内容
为了克服现有技术的缺陷,使网络资源和服务更加方便地、并且形式统一地注册和查询,本发明提出一种网络资源与服务的统一描述方法,所述方法利用本体对网络资源和服务进行统一描述,在其中涉及到语义网的概念。主要针对互联网的服务和资源的查找,提出以本体描述为基础,将资源和服务通过属性联系起来的统一描述方法,以实现对资源和服务的统一查找。本发明涉及的搜索范围不同于搜索引擎,搜索引擎只对网页进行搜索,而本发明的搜索范围是互联网上的各种服务和资源。为实现以上统一描述方法的本体描述,本发明对网络上的资源和服务定义了一个本体的类层次,并描述出他们可能具有的属性,以及属性和属性之间的关联,并预留今后的扩展。本发明分别提出以资源为出发点和以服务为出发点的两种不同描述方法,可以在针对具体情况时进行选择。根据以上方法建立起本体框架后,加上适当的推理规则,就可以实现对网络资源和服务的完整语义查找。
本发明的目的是这样实现的:一种网络资源与服务的统一描述方法,包括:包含局域网和广域网以及移动通讯网的互联网,其关键步骤是:
步骤1:定义本体的类的层次;
步骤2:定义属性;
步骤3:用户向注册中心注册其提供的资源和服务;
步骤4:用户端对网络资源进行查询。
本发明产生的有益效果是:本发明提出了一种对网络资源和服务的统一描述方法,将客户需要从网络上获得的网络资源和服务做了形式上的统一,基于这种统一可以实现资源和服务的注册和查询。其意义在于将现存的各种关联不大的注册和查询方法联系起来,用户可以在一个专用的资源和服务查询端对网络的所有事物进行更有效的查询,给用户提供了极大的便利。另外,本发明将本体的概念引入描述部分,用户进行查询的时候可以摆脱现有搜索引擎的基于关键字的方法,而采用一种基于本体描述的具有推理能力的查询方法。所以本发明可能改变用户对“网络搜索”意义的理解,为今后的网络搜索以及资源和服务的注册和查询提供一种新的思路。
附图说明
下面结合附图和实施例对本发明作进一步说明。
图1是实施例一的语义网层次的示意图;
图2是实施例二构建的本体的类层次图;
图3是实施例二的个体示意图;
图4是实施例三构建的本体的类层次图;
图5是实施例三的具体服务类层次图。
具体实施方式
实施例一:
本实施例利用本体来描述服务和资源的类层次、它们的属性以及属性和属性之间的关系,以将两者关联起来,在互联网服务注册阶段可以做一个形式统一的注册,查询时可以以资源或服务为出发点,关联到另一方面。同时,本体是语义网的一部分,利用本体语言的描述,以及推理规则的定义,可以实现查找时的语义功能。本发明利用本体语言对网络资源和服务进行统一描述,其中“本体”这个术语来自于哲学,它是研究世界上的各种实体以及他们是怎么关联的科学。一个“Web本体”可能包含了类,属性和他们的实例的描述。
建立起本体的类,属性和他们的实例。领域本体是对某个具体领域的事物和属性描述的集合,本实施例实际上建立起一个关于网络资源和服务的领域本体框架,利用本体特有的特点来解决互联网现有的服务和资源的注册和查找中的一些问题。领域本体的建立是采用不断完善的方式,先将基本的类框架搭建起来。即建立起上层类层次,描述它们的属性以及属性和属性之间的关系,服务和资源的类层次本体描述是整个系统的基础。因为互联网在不断发展,服务的种类是越来越多的。在描述类的层次的时候必须按照一个可扩展的框架来搭建,就是在一个新的服务产生的时候我们可以马上将其插入本体中恰当的位置。本实施例以服务的交互性为标准来划分第一个层次,可以搭建一个可扩展的框架。对于服务的具体属性,可以根据服务本身的特性来扩展。对资源也是采取相同的方法。
对于本体描述,OWL形式语义说明怎么获得它的逻辑结论,也就是说,不是逐字写在本体中的事实,而是语义蕴涵的事实。这些蕴涵可以是基于本实施例所描述的本体中,也可以由本领域本体和其它领域本体合并的描述中得到。通过多个本体的合并,可以获得更多的细节的信息。
为了使网络资源和服务更加方便地、并且形式统一地注册和查询,本实施例利用本体对网络资源和服务进行统一描述,其中涉及到语义网的概念。
语义网并不是一种全新的网络,它的目的是使包含在它内部的信息拥有明确定义的语义,这种语义更多的是针对机器而不是针对人来说的。网络是一个可导航的空间,在其中每一个URI都映射到一个资源。“语义”意味着机器可处理的,“语义”确定了机器能够对人的帮助。如图1所示,语义网的层次结构主要包括Unicode和URI、XML+NS+xmlschema、RDF+rdfschema、Ontologyvocabulary、Logic、Proof、Trust等几个层次。其中Unicode是字符编码的统一标准;URI是网络资源的标识形式;XML(可扩展标记语言)定义了结构化的数据传输格式,但它不包含任何语义;NS(命名空间)就是Namespace,它将同名但意义不同的资源放在不同的名字空间里来做区分;xmlschema统一了XML数据格式的规范;RDF(资源描述框架)是语义描述的基础,它定义了描述资源以及陈述事实的基本方式:主语、谓语、宾语的三元组;rdfschema是一种RDF词汇描述语言,在RDF之上定义了一个最小的语义模型支持复杂词汇的建模;Ontology(本体)是一种明确的语义定义方式,通过Ontology,机器可以理解数据的语义,从而可以帮助人来处理一些以前都需要人来做的事情,本体只是一个概念,具体来描述本体的语言有很多,此文中以OWL为具体实现方式。在以上基础上,语义网可以完成Logic(逻辑)、Proof(证明)、Trust(认证)的功能。
Logic层在本体所描述的知识之上提供逻辑推理能力(基于规则)。例如,定义这样一个规则,为公司中工作20年的能够被授予“资深员工”的称号,张三已经为公司工作了22年。于是通过逻辑规则能够推理得出:张三是公司的“资深员工”。
有了基本的对事实的逻辑规则的定义,就能够提供对事实的复杂Proof。例如,公司的历史记录记载张三从1984年到1991在公司的技术部工作,1991年到2006年在公司的市场部工作,而且从逻辑规则中可以知道这两个时间段是互斥的,即它们的交集为空集,所以有计算7+15=22,22>20,所以可以得到一个Proof:张三是公司的“资深员工”。当然,在语义网中的推理和证明并不像例子这么简单,可能每个结论都由大量的信息通过逻辑来组成。
在本实施例中定义了一个对网络资源和服务的Ontology描述,用到的Ontology语言是W3C组织(万维网联盟)提出的OWL WEB本体语言。这种本体描述语言,可以用来描述Web文档和应用中内在的类和关系。OWL提供了三种表达能力递增的子语言:OWL Full,OWL DL和OWL Lite。三个子语言的限制由少到多,其表达能力依次下降,但可推理能力依次增强。类、个体和属性是OWL中的三个重要的基本概念。
类提供了组织具有相似特征的资源的一种抽象方式,一个领域中的最基本概念应分别对应于各个分类层次树的根。OWL中的所有个体都是类owl:Thing的成员。因此,各个用户自定义的类都隐含地是owl:Thing的一个子类。要定义特定领域的根类,只需将它们声明为一个具名类即可。可以用owl:Class来创建类,用rdfs:subClassOf来构造类的层次关系。
<owl:Class rdf:ID=″EdibleThing″>...</owl:Class>
<owl:Class rdf:ID=″Pasta″>
<rdfs:subClassOf rdf:resource=″#EdibleThing″/>
</owl:Class>
在上面例子的第一行中定义了一个叫EdibleThing的类,下面三行说明Pasta类是EdibleThing类的子类。
除了描述类,还希望能够描述类的成员。通常认为类的成员是所关心的范畴中的一个个体。rdf:type是一个RDF属性,用于关联一个个体和它所属的类。
<owl:Thing rdf:ID=″CentralCoastRegion″/>
<owl:Thing rdf:about=″#CentralCoastRegion″>
<rdf:type rdf:resource=″#Region″/>
</owl:Thing>
<Region rdf:ID=″CentralCoastRegion″/>
前四行通过rdf:type的描述方式定义了一个Region类的个体CentralCoastRegion,最后一行是个体的一个简单描述方式,它和前四行的描述效果是一样的。
如果仅允许定义层次分类,那么这个类和个体的世界也许会显得相当单调。属性使得可以断言关于类成员的一般事实以及关于个体的具体事实。属性有两种类型:对象属性和数据类型属性。对象属性反映的是两个类的实例间的关系,而数据类型属性反映的是类实例与RDF文字或XML Schema数据类型间的关系。一个属性有其定义域和值域,定义域说明此属性由哪个类所拥有,值域是说明哪个类可以作为这个属性的值而存在。
<owl:ObjectPropertyrdf:ID=″madeFromGrape″>
<rdfs:domain rdf:resource=″#Wine″/>
<rdfs:range rdf:resource=″#WineGrape″/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID=″yearValue″>
<rdfs:domain rdf:resource=″#VintageYear″/>
<rdfs:range rdf:resource=″&xsd;positiveInteger″/>
</owl:DatatypeProperty>
上例中,前四行定义了一个对象属性,它的定义域是Wine,它的值域是WineGrape。后面四行定义了一个数据类型属性,它的定义域是VintageYear,它的值域是正整数。属性按其特性可以分为传递属性、对称属性、函数型属性、反函数型属性、逆属性。通过对属性的特性进行详细的说明,OWL提供了一种强有力的机制以增强对于一个属性的推理。
本实施例的基本步骤是:
步骤1:定义本体的类的层次;
步骤2:定义属性;
步骤3:用户向注册中心注册其提供的资源和服务;
步骤4:用户端对网络资源进行查询。
在本实施例建立一个本体,其中包括资源的分类和服务的分类,还有另外一些相关参数的分类。资源和服务之间利用一定的属性关系来关联。这样通过一般的认知来区分网络上的资源和服务。但在一次注册或查询的过程中,可以兼顾到两者的关系及其特有的属性特征。这种方法并不是要把网络资源和服务统一成一种形式,因为资源和服务的本质的特性还是有区别的,随着互联网的发展它们的自身形式都越来越丰富,种类越来越多。对于统一的注册中心来说,要注册资源还是服务是一个麻烦的问题。本实施例利用本体的方法将资源和服务以网状的形式关联起来,能够为用户提供对资源和服务更加全面的认识。
在对服务进行分类的时候,本实施例采取的方法是:将现有的网络服务分成交互和非交互的两大类。交互的服务是指用户与人之间的交互,例如VOIP和聊天服务;非交互的服务是指用户与服务器之间的交互。交互型服务又可以根据交互内容的不同来进行划分,包括即时消息、文件、语音、视频等几类。非交互型的服务可以以服务器的类型来划分子类,包括http、ftp、mail等几类,而子类中还有子类,而且这些子类可能随着互联网的发展不断扩充。扩充的方法可以采用在此本体中直接添加子类,也可以将其它领域本体合并到此本体中来。
实施例二:
对于用户来说,有两种区别比较大的查询意图。一种是想获得互联网上一个实实在在的资源,另一种是想获得一项具体的服务。本发明提出两种方案,分别从资源和服务的角度出发,来对两者做统一的描述,以满足两类用户的需求。
本实施例是实施例一的以资源为出发点的查询的具体实施例,步骤如下:
1)定义网络资源和服务领域的几个最上层的父类,包括互联网所有资源的父类network_resource,互联网所有服务的父类network_service和代表Qos的父类network_service_Qos;
2)定义network_resource的子类,包括video、voice、file、message等几类,并且增加为服务做索引的一类service_index;
3)定义network_service的子类,根据服务的交互与非交互的特点先将服务划分为两大类,interactive和non_interactive;
4)定义network_service_Qos下的子类,预先定义一个具有代表性的transmission_speed;
5)定义network_service下interactive的子类,对于交互型服务而言,根据客户之间交互服务的内容来划分。其子类包括:inter_video、inter_instant_message、inter_file、inter_voice等几类;
6)定义network_service下non_interactive的子类,对于非交互型服务而言,根据客户与什么类型的服务器进行交互来划分类别,其子类包括:non_inter_http、non_inter_mail、non_inter_ftp等几类;
7)可以根据non_inter_http的特点将其子类定义为:non_inter_http_video,non_inter_http_voice,non_inter_http_webservice等几类;
8)可以根据network_resource下video的特点将其子类定义为:video_section,movie,mv,trans_video等几类;
步骤2定义属性中的子步骤:
1)定义属性via,via属性用来表示资源通过哪种服务来进行提供,其定义域是network_resource,其值域是network_service;
2)定义其它属性,根据服务的特性添加has_Qos_speed属性,用来表示服务的传输速率的等级,其定义域是network_service,其值域是transmission_speed;
3)定义其它需要的对象属性和数据类型属性;
步骤3用户向注册中心注册其提供的资源和服务;
步骤4用户端对网络资源进行查询中的子步骤:
1)典型的方式是通过资源的名称来查找;
2)当用户并不知道资源的名称时,可以由资源的某个属性来查找这个资源;
3)当用户希望得到某种特定的服务质量时,可以由服务的has_Qos_speed属性值的等级来查询;
4)若要支持完整的推理,可以在将某些属性定义为对象属性,再在推理机中添加推理规则,通过一系列的逻辑和证明来完成一个复杂的推理过程;
5)若要支持其他更加复杂的推理,还可以采取将此本体与一个事先定义的其它本体合并的方法来完成。
以下为本实施例的一个具体示例:
查询端在查找时明确指出要查找的是一个资源。图2是本实施例示例的类的层次图。在OWL语言中,owl:Thing是一切类的父类。本示例中,定义了三个owl:Thing的直接子类,它们分别是network_service、network_service_Qos和network_resource等。network_service是所有服务的父类,network_resource是所有资源的父类,network_service_Qos是所有Qos的父类。其中Qos就以传输速率作为代表来验证。
此外,共定义了3个属性,包括2个对象属性:has_Qos_speed和via,1个数据类型属性:singer。has_Qos_speed属性用来表示服务的传输速率的等级,via属性用来表示资源通过哪种服务来进行提供,singer属性用来表示歌手的名称。
MV(音乐电视)资源本身会带有其信息,包括MV的编码格式,MV的长度,歌手名等等,这些都是这个MV资源的属性。另外,会为MV这个类添加一个对象属性via,其值是一种服务,表示这个资源通过某种服务来获得。例如,选择这个MV的via值是ftp,表示这个MV是通过ftp文件传输的方式获得的。通过via属性的值,很容易找到这个ftp服务,也就很容易找到ftp服务的一些对应的信息值,最重要的就是它能提供的下载速率。
如图3所示,在示例中创建了mv类的一个个体,名字为Beat_it。为这个个体添加两个属性,一个是关于它自身信息的数据类型属性:singer,singer属性的值是string类型的“Michael Jackson”;另一个属性表示这个资源由什么服务提供:via,via属性的值是non_inter_ftp_test。
如图3所示,non_inter_ftp_test这个服务有自己的属性和属性值,在示例中可以看到non_inter_ftp_test有一个has_Qos_speed的属性,它的属性值是transmission_speed_2。
其注册和查询的步骤如下:
步骤1,能够提供MV资源的用户将资源注册到分布式注册中心。singer属性的值为string类型的“Michael Jackson”,via属性的值是non_inter_ftp_test,has_Qos_speed属性的值是transmission_speed_2。
步骤2,用户端对网络资源进行查询。
1)典型的方式是通过资源的名称Beat_it来查找。
2)当用户并不知道资源的名称时,可以由资源的singer属性来查找这个资源。
3)当用户希望得到某种特定的服务质量时,可以由服务的has_Qos_speed属性值的等级来查询。
4)若要支持完整的推理,可以在将singer属性定义为对象属性。再在推理机中添加推理规则:唱片销量过100万的歌手是“明星歌手”,将Michael Jackson这个个体的属性值做一个proof,可以推出Michael Jackson是“明星歌手”。当用户查询明星歌手或其同义词时,就可以查出Michael Jackson。而在定义的时候并没有定义Michael Jackson为“明星歌手”,这是通过一系列的逻辑和证明来完成的。
5)若要支持其他更加复杂的推理,还可以采取将此本体与一个事先定义的关于职业的本体(其中包括歌手)合并的方法。
这种方法的优点是对资源的查找非常清楚,但对于注册和调用联系较紧密的服务的查询过程显得不是很清楚。为此,还专门在资源的分类下面添加一项service_index,用户可以通过查这一项直接转向对服务的查找。
实施例三:
本实施例是实施例一的以服务为出发点的查询的具体实施例,步骤如下:
1)定义网络资源和服务领域的几个最上层的父类,包括互联网所有资源的父类network_resource,互联网所有服务的父类network_service和代表Qos的父类network_service_Qos;
2)定义network_resource的子类,包括video、voice、file、message等几类;
3)定义network_service的子类,根据服务的交互与非交互的特点先将服务划分为两大类,interactive和non_interactive;
4)定义network_service_Qos下的子类,预先定义一个具有代表性的transmission_speed;
5)定义network_service下interactive的子类,对于交互型服务而言,根据客户之间交互服务的内容来划分,其子类包括:inter_video、inter_instant_message、inter_file、inter_voice等几类;
6)定义network_service下non_interactive的子类,对于非交互型服务而言,根据客户与什么类型的服务器进行交互来划分类别,其子类包括:non_inter_http、non_inter_mail、non_inter_ftp等几类;
7)根据non_inter_http的特点将其子类定义为:non_inter_http_video,non_inter_http_voice,non_inter_http_webservice等几类;
步骤2定义属性中的子步骤:
1)定义属性has_resource,has_resource属性表示提供这个服务需要伴随得到的资源是什么,其定义域是是network_service,其值域是network_resource;
2)定义其它属性,根据服务的特性添加has_Qos_speed属性,用来表示服务的传输速率的等级,其定义域是network_service,其值域是transmission_speed;
3)定义其它需要的对象属性和数据类型属性;
步骤3用户向注册中心注册其能提供的资源和服务;
步骤4用户端对网络资源进行查询的子步骤:
1)典型的方式是通过对的服务名的查找来完成的;
2)对于查询和调用联系紧密的服务,用户查找可以得到其自身的特有信息;对于其他服务,用户查找可以获得领域本题里定义的响应信息;
3)对于普通的web services服务就可以直接调用;对于其它服务,可以通过服务的特征和参数进行后续地调用。
以下为一具体示例:
查询端在查找时明确指出要查找的是一个服务。图4是本实施例的示例的类的层次图。在测试本体示例中,类定义与实施例二的定义基本相同,区别在于舍去资源下面的service_index分类。owl:Thing的直接子类还是network_service、network_service_Qos和network_resource等。但在属性的定义上与方案一有了很大的区别。共定义了2个属性,包括2个对象属性:has_Qos_speed和has_resource。has_resource属性表示提供这个服务需要伴随得到的资源是什么。
以服务为中心的查找关注的是一类查找和注册紧密联系的服务。如图5所示,在non_inter_http类下面的non_inter_http_webservices子类中,以一个e_learning为例。e_leaming服务有chemistry、physics和english几种类型,english服务可以由listening、writing、speaking和reading子服务组成。有了这个服务的层次,再通过web services自身调用的特性,可以将这类服务处理得很好。
其注册和查询的步骤如下:
步骤1,能够提供english服务的用户将服务注册到分布式注册中心。包括english服务中的子服务:listening、writing、speaking和reading
步骤2,用户端对网络服务进行查询。
1)典型的方式是通过对的服务名的查找来完成的。
2)对于查询和调用联系紧密的服务(如web services),用户查找可以得到其自身的特有信息(如web services中的wsdl文档)。对于其他服务,用户查找可以获得领域本题里定义的响应信息。
3)对于普通的web services服务就可以直接调用。对于其它服务,我们可以通过服务的特征和参数进行后续地调用。
这种方法的优点是对服务的查找非常清楚。但在查找资源时,还是有一定的不方便性。在这个问题上可以利用给每个服务类型定义一个has_resource对象属性来解决。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求书的保护范围为准。
Claims (3)
1.一种网络资源与服务的统一描述方法,包括:包含局域网和广域网以及移动通讯网的互联网,其特征在于所述的步骤:
步骤1:定义本体的类的层次;
步骤2:定义属性;
步骤3:用户向注册中心注册其提供的资源和服务;
步骤4:用户端对网络资源进行查询。
2.根据权利要求1所述的一种网络资源与服务的统一描述方法,其特征在于以查询资源为出发点的步骤:
步骤1定义本体的类的层次中的子步骤:
1)定义网络资源和服务领域的几个最上层的父类,包括互联网所有资源的父类network_resource,互联网所有服务的父类network_service和代表Qos的父类network_service_Qos;
2)定义network_resource的子类,包括video、voice、file、message等几类,并且增加为服务做索引的一类service_index;
3)定义network_service的子类,根据服务的交互与非交互的特点先将服务划分为两大类,interactive和non_interactive;
4)定义network_service_Qos下的子类,预先定义一个具有代表性的transmission_speed;
5)定义network_service下interactive的子类,对于交互型服务而言,根据客户之间交互服务的内容来划分。其子类包括:inter_video、inter_instant_message、inter_file、inter_voice等几类;
6)定义network_service下non_interactive的子类,对于非交互型服务而言,根据客户与什么类型的服务器进行交互来划分类别,其子类包括:non_inter_http、non_inter_mail、non_inter_ftp等几类;
7)可以根据non_inter_http的特点将其子类定义为:non_inter_http_video,non_inter_http_voice,non_inter_http_webservice等几类;
8)可以根据network_resource下video的特点将其子类定义为:video_section,movie,mv,trans_video等几类;
步骤2定义属性中的子步骤:
1)定义属性via,via属性用来表示资源通过哪种服务来进行提供,其定义域是network_resource,其值域是network_service;
2)定义其它属性,根据服务的特性添加has_Qos_speed属性,用来表示服务的传输速率的等级,其定义域是network_service,其值域是transmission_speed;
3)定义其它需要的对象属性和数据类型属性;
步骤3用户向注册中心注册其提供的资源和服务;
步骤4用户端对网络资源进行查询中的子步骤:
1)典型的方式是通过资源的名称来查找;
2)当用户并不知道资源的名称时,可以由资源的某个属性来查找这个资源;
3)当用户希望得到某种特定的服务质量时,可以由服务的has_Qos_speed属性值的等级来查询;
4)若要支持完整的推理,可以在将某些属性定义为对象属性,再在推理机中添加推理规则,通过一系列的逻辑和证明来完成可以完成一个复杂的推理过程;
5)若要支持其他更加复杂的推理,还可以采取将此本体与一个事先定义的其它本体合并的方法来完成。
3.根据权利要求1所述的一种网络资源与服务的统一描述方法,其特征在于以查询服务为出发点的步骤:
步骤1定义本体的类的层次中的子步骤:
1)定义网络资源和服务领域的几个最上层的父类,包括互联网所有资源的父类network_resource,互联网所有服务的父类network_service和代表Qos的父类network_service_Qos;
2)定义network_resource的子类,包括video、voice、file、message等几类;
3)定义network_service的子类,根据服务的交互与非交互的特点先将服务划分为两大类,interactive和non_interactive;
4)定义network_service_Qos下的子类,预先定义一个具有代表性的transmission_speed;
5)定义network_service下interactive的子类,对于交互型服务而言,根据客户之间交互服务的内容来划分,其子类包括:inter_video、inter_instant_message、inter_file、inter_voice等几类;
6)定义network_service下non_interactive的子类,对于非交互型服务而言,根据客户与什么类型的服务器进行交互来划分类别,其子类包括:non_inter_http、non_inter_mail、non_inter_ftp等几类;
7) 根据non_inter_http的特点将其子类定义为:non_inter_http_video,non_inter_http_voice,non_inter_http_webservice等几类;
步骤2定义属性中的子步骤:
1)定义属性has_resource,has_resource属性表示提供这个服务需要伴随得到的资源是什么,其定义域是是network_service,其值域是network_resource;
2)定义其它属性,根据服务的特性添加has_Qos_speed属性,用来表示服务的传输速率的等级,其定义域是network_service,其值域是transmission_speed;
3)定义其它需要的对象属性和数据类型属性;
步骤3用户向注册中心注册其能提供的资源和服务;
步骤4用户端对网络资源进行查询的子步骤:
1)典型的方式是通过对的服务名的查找来完成的;
2)对于查询和调用联系紧密的服务,用户查找可以得到其自身的特有信息;对于其他服务,用户查找可以获得领域本题里定义的响应信息;
3)对于普通的web services服务就可以直接调用;对于其它服务,可以通过服务的特征和参数进行后续地调用。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101217491A CN101141455B (zh) | 2007-09-13 | 2007-09-13 | 一种网络资源与服务的统一描述方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101217491A CN101141455B (zh) | 2007-09-13 | 2007-09-13 | 一种网络资源与服务的统一描述方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101141455A true CN101141455A (zh) | 2008-03-12 |
CN101141455B CN101141455B (zh) | 2011-06-22 |
Family
ID=39193199
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101217491A Expired - Fee Related CN101141455B (zh) | 2007-09-13 | 2007-09-13 | 一种网络资源与服务的统一描述方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101141455B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101499971B (zh) * | 2009-03-09 | 2011-02-16 | 天津大学 | 服务网络性能优化系统 |
CN102158551A (zh) * | 2011-03-30 | 2011-08-17 | 沈益民 | 物联网信息源统一描述和访问方法 |
CN102223414A (zh) * | 2011-06-21 | 2011-10-19 | 华北电力大学 | 一种实现网络资源命名与定位的方法 |
CN101562633B (zh) * | 2009-05-27 | 2012-08-22 | 天津大学 | 可视化服务网络用户交互系统 |
CN103370707A (zh) * | 2011-02-24 | 2013-10-23 | 瑞典爱立信有限公司 | 用于媒体分类的方法和服务器 |
CN103778000A (zh) * | 2014-01-26 | 2014-05-07 | 北京仿真中心 | 一种基于本体的仿真服务语义描述方法 |
CN110516079A (zh) * | 2019-08-29 | 2019-11-29 | 北京大学 | 一种rdf对象模型类层次树建立方法及系统 |
CN110636093A (zh) * | 2018-06-25 | 2019-12-31 | 中兴通讯股份有限公司 | 微服务注册和发现方法、设备、存储介质以及微服务系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1968322A (zh) * | 2006-09-08 | 2007-05-23 | 中山大学 | 一种Web服务发现和集成代理系统 |
-
2007
- 2007-09-13 CN CN2007101217491A patent/CN101141455B/zh not_active Expired - Fee Related
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101499971B (zh) * | 2009-03-09 | 2011-02-16 | 天津大学 | 服务网络性能优化系统 |
CN101562633B (zh) * | 2009-05-27 | 2012-08-22 | 天津大学 | 可视化服务网络用户交互系统 |
CN103370707A (zh) * | 2011-02-24 | 2013-10-23 | 瑞典爱立信有限公司 | 用于媒体分类的方法和服务器 |
CN102158551A (zh) * | 2011-03-30 | 2011-08-17 | 沈益民 | 物联网信息源统一描述和访问方法 |
CN102223414A (zh) * | 2011-06-21 | 2011-10-19 | 华北电力大学 | 一种实现网络资源命名与定位的方法 |
CN102223414B (zh) * | 2011-06-21 | 2013-10-16 | 华北电力大学 | 一种实现网络资源命名与定位的方法 |
CN103778000A (zh) * | 2014-01-26 | 2014-05-07 | 北京仿真中心 | 一种基于本体的仿真服务语义描述方法 |
CN110636093A (zh) * | 2018-06-25 | 2019-12-31 | 中兴通讯股份有限公司 | 微服务注册和发现方法、设备、存储介质以及微服务系统 |
CN110516079A (zh) * | 2019-08-29 | 2019-11-29 | 北京大学 | 一种rdf对象模型类层次树建立方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN101141455B (zh) | 2011-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101141455B (zh) | 一种网络资源与服务的统一描述方法 | |
Abel et al. | Cross-system user modeling and personalization on the social web | |
Yu et al. | Linked open data | |
CN104903886B (zh) | 基于社交图谱信息的结构化搜索查询 | |
Speiser et al. | Integrating linked data and services with linked data services | |
Broens et al. | Context-aware, ontology-based service discovery | |
Lanthaler et al. | A semantic description language for restful data services to combat semaphobia | |
US20080109481A1 (en) | Context based network search | |
CN102780580B (zh) | 一种基于信任的组合服务优化方法 | |
CN104462460A (zh) | 一种构造rest风格的本体标注可视化系统的方法 | |
CN100492369C (zh) | 扩展uddi实现语义及个性化查询的方法及系统 | |
Broens | Context-aware, ontology based, semantic service discovery | |
Schade et al. | Augmenting SDI with linked data | |
Seghir et al. | A decentralized framework for semantic web services discovery using mobile agent | |
Meshram | Evolution of modern web services–rest api with its architecture and design | |
Bozzon et al. | A framework for integrating, exploring, and searching location-based web data | |
Brambilla et al. | Semantic resource framework | |
Xie et al. | Enabling personalization services on the edge | |
Loutas et al. | The semantic public service portal (S-PSP) | |
Degbelo et al. | Open geodata reuse: towards natural language interfaces to web APIs | |
Bergweiler | Interactive service composition and query | |
Arabshian et al. | Gloserv: Global service discovery using the owl web ontology language | |
Calcina-Ccori et al. | Location-aware discovery of services in the IoT: a Swarm approach | |
Arabshian et al. | Ontology-based service discovery front-end interface for GloServ | |
Ziembicki | Distributed search in semantic web service discovery |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110622 Termination date: 20200913 |
|
CF01 | Termination of patent right due to non-payment of annual fee |