CN104834681A - 服务推荐方法及装置 - Google Patents

Abstract

本发明提供一种服务推荐方法及装置。方法包括：获取用户输入的目标需求的描述信息；根据目标需求的描述信息，将目标需求分解为至少一个子需求；获取至少一个子需求中每个子需求对应的服务列表；向用户返回每个子需求对应的服务列表。本发明可以向用户直接推荐服务，提高用户获取服务的效率，满足用户的应用需求。

Description

服务推荐方法及装置

【技术领域】

本发明涉及互联网技术领域，尤其涉及一种服务推荐方法及装置。

【背景技术】

随着互联网技术的飞速发展，基于互联网向用户推荐信息的应用越来越多。通过这些应用，用户可以从互联网上获取各种信息。

目前，最为常见的一种基于互联网向用户推荐信息的应用主要是：根据用户的位置信息，向用户推荐附近的商户信息。对用户来说，根据该应用推荐的信息，可以获知附近的商户信息，如果用户需要使用有关商户提供的服务，则需要亲自去往该商户并使用有关服务。由此可见，这种方式推荐给用户的仅仅是一些商户信息，而不是用户真正需要的服务，导致用户使用服务的效率较低，不能满足用户的应用需求。

【发明内容】

本发明的多个方面提供一种服务推荐方法及装置，用以向用户直接推荐服务，提高用户获取服务的效率，满足用户的应用需求。

本发明的一方面，提供一种服务推荐方法，包括：

获取用户输入的目标需求的描述信息；

根据所述目标需求的描述信息，将所述目标需求分解为至少一个子需求；

获取所述至少一个子需求中每个子需求对应的服务列表；

向所述用户返回所述每个子需求对应的服务列表。

本发明的另一方面，提供一种服务推荐装置，包括：

第一获取模块，用于获取用户输入的目标需求的描述信息；

分解模块，用于根据所述目标需求的描述信息，将所述目标需求分解为至少一个子需求；

第二获取模块，用于获取所述至少一个子需求中每个子需求对应的服务列表；

推荐模块，用于向所述用户返回所述每个子需求对应的服务列表。

由上述技术方案可知，在本发明中，用户在输入目标需求的描述信息后，可由服务推荐装置根据目标需求的描述信息，将目标需求拆分为至少一个子需求，进而获取每个子需求对应的服务列表，向用户返回每个子需求对应的服务列表，以供用户选择使用的服务，实现了向用户直接推送服务的目的，由于直接推送给用户的是服务，而不是服务提供商的信息，有利于提高用户使用服务的效率，满足用户的应用需求。

【附图说明】

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例提供的服务推荐方法的流程示意图；

图2为本发明一实施例提供的目标需求分解出至少一个子需求的状态示意图；

图3为本发明一实施例提供的简单本体树的结构示意图；

图4为本发明一实施例提供的服务推荐装置的结构示意图；

图5为本发明另一实施例提供的服务推荐装置的结构示意图。

【具体实施方式】

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明一实施例提供的服务推荐方法的流程示意图。如图1所示，该方法包括：

101、获取用户输入的目标需求的描述信息。

102、根据上述目标需求的描述信息，将目标需求分解为至少一个子需求。

103、获取至少一个子需求中每个子需求对应的服务列表。

104、向用户返回每个子需求对应的服务列表。

本实施例提供一种服务推荐方法，可用于向用户推荐服务，具体可由服务推荐装置来执行。该服务推荐装置具体可以位于用户终端中实现，即作为用户终端的功能模块实现。或者，该服务推荐装置也可以独立于用户终端，但可以与用户终端相互通信，例如可以作为一服务提供端位于服务器上实现。可选的，用户终端可以是但不限于：手机、PC、平板电脑等。

当用户需要使用某种服务时，便会产生使用服务的需求。为便于描述，本实施例将用户使用服务的需求记为目标需求。对用户来说，需要用一定方式对目标需求进行描述，并将目标需求的描述信息提供给服务推荐装置，以便于服务推荐装置能够了解用户的需求。

可选的，服务推荐装置可以通过用户终端向用户提供一交互界面，以供用户输入目标需求的描述信息。本实施例对交互界面的实现形式不做限定。用户通过该交互界面输入目标需求的描述信息。对服务推荐装置来说，可以通过该交互界面获取用户输入的目标需求的描述信息。

上述目标需求的描述信息描述了用户需要使用的服务。例如，假设用户在机场需要购票，则可以输入“购票服务”等字样作为上述描述信息。又例如，假设用户在电影院需要购票，则可以输入“购买片名为xxx的电影票”等字样作为上述描述信息。

用户的目标需求可能涉及多个服务。例如，用户看电影的需求，涉及购买电影票的服务和购买零食的服务。又例如，用户在机场办理登机的需求，涉及购买机票的服务、办理托运的服务以及办理登机的服务等等。基于此，在获取用户输入的目标需求的描述信息之后，服务推荐装置可以根据目标需求的描述信息，将目标需求分解为至少一个子需求。每个子需求对应一类服务。

在将目标需求分解为至少一个子需求后，服务推荐装置进一步获取每个子需求对应的服务列表，然后将每个子需求对应的服务列表推荐给用户，以供用户选择所使用的服务。其中，每个子需求对应的服务列表包括至少一个可用的服务。

由上述可见，在本实施例中，用户在输入目标需求的描述信息后，可由服务推荐装置根据目标需求的描述信息，将目标需求拆分为至少一个子需求，进而获取每个子需求对应的服务列表，向用户返回每个子需求对应的服务列表，以供用户选择使用的服务，实现了向用户直接推送服务的目的。由于本实施例直接推送给用户的是服务，而不是服务提供商的信息，因此用户可以直接使用该服务，而不需要先去往服务提供商再使用服务，有利于提高用户使用服务的效率，满足用户的应用需求。

可选的，服务推荐装置可以获取所有子需求对应的服务列表，然后统一将所有子需求对应的服务列表推荐给用户，供用户从每个子需求对应的服务列表中选择用于实现每个子需求的服务。

举例说明，假设用户要看电影，则用户输入“观看片名为xxx的电影”的字样，则服务推荐装置获取用户输入的“观看片名为xxx的电影”的字样后，将用户的需求拆分为两个子需求，分别为购票子需求和购买零食子需求，然后获取购票子需求对应的至少一个购票服务，假设包括：购买8点-10点播放的片名为xxx的电影的购票服务，购买12点-14点播放的片名为xxx的电影的购票服务，以及购买16点-18点播放的片名为xxx的电影的购票服务等，并获取购买零食子需求对应的至少一个零食服务，假设包括：购买爆米花的零食服务、购买可乐的零食服务、购买瓜子的零食服务、购买冰激凌的零食服务等；然后一并将购票子需求对应的至少一个购票服务以及购买零食子需求对应的至少一个零食服务以服务列表的形式推荐给用户，以供用户选择所使用的购票服务和零食服务。值得说明的是，用户选择使用购票服务后，该购票服务会向用户返回购买的电影票的场次和座位号，进一步还可以向用户提供去往演播厅的路线引导信息等；用户选择使用零食服务后，该服务会直接为用户购买相应零食并放置到用户所在演播厅的座位上。由此可见，这种方式可以直接向用户提供服务，有利于提高用户使用服务的效率，满足用户的应用需求。

可选的，服务推荐装置也可以按照子需求之间的先后顺序或依赖关系，逐一获取子需求对应的服务列表并返回给用户，当用户从服务列表中选择并使用服务之后，继续获取下一子需求对应的服务列表并返回给用户。

举例说明，假设用户要乘坐去往xxx的航班，则用户输入“乘坐去往xxx的航班”的字样，则服务推荐装置获取用户输入的“乘坐去往xxx的航班”的字样后，将用户的需求拆分为三个子需求，分别为购票子需求、托运子需求和登机子需求，然后获取购票子需求对应的至少一个购票服务，假设包括：购买8点起飞的去往xxx的航班的购票服务，购买12点起飞的去往xxx的航班的购票服务，以及购买16点起飞的去往xxx的航班的购票服务等，将该购票子需求对应的至少一个购票服务以服务列表的形式推荐给用户；用户选择购买12点起飞的去往xxx的航班的购票服务后，该购票服务会为用户购买12点起飞的去往xxx的航班，并会将航班及座位信息返回给用户；之后，获取托运子需求对应的至少一个托运服务，假设包括：10-15kg(小件)的托运服务、15-20kg的托运服务、30kg以上的托运服务等，将托运子需求对应的至少一个托运服务以服务列表的形式推荐给用户；用户从中选择使用的托运服务，该托运服务会帮用户办理托运手续并将用户的行李送到托运地点；之后，获取登机子需求对应的登机服务，并将登记子需求对应的登机服务推荐给用户，用户选择使用登记服务，登机服务会自动为用户办理登机有关的事务，并最终向用户提供登机牌。由此可见，这种方式可以直接向用户提供服务，有利于提高用户使用服务的效率，满足用户的应用需求。

在一可选实施方式中，可以预先设置一服务数据库，该服务数据库用于存储服务。具体的，可以预先注册服务。将已注册的服务的信息存储到服务数据库中。基于此，服务推荐装置在获得子需求后，可以根据每个子需求在服务数据库中进行匹配，以获得每个子需求对应的服务列表。在该实施方式中，通过服务数据库对已注册的服务进行管理，不仅便于对服务进行管理，服务推荐装置只需在服务数据库中进行匹配即可获得每个子需求对应的服务列表，获取子需求对应的服务列表的过程较为简单，有利于提高获取子需求对应的服务列表的效率。

可选的，为了便于访问服务数据库，可以为服务数据库设置一套访问用API是很有必要的。基于此，可以预先为服务数据库设置供外部访问该服务数据库使用的API，则服务推荐装置可以通过API访问服务数据库，实现对服务数据库的增删改查之类的操作。

随着互联网技术的发展，上述向用户推荐服务的方案可以基于互联网实现。为了通过互联网向用户推荐服务，首先需要以互联网所支持且能够被机器所理解的方式来表示服务。语义web是未来互联网发展的愿景，在语义web中，信息都有它自身显示的意义，这样使得机器可以自动的对其进行处理，并且与互联网上的其他信息进行集成。语义web拥有XML自定义标签的功能，并且采用RDF来灵活的展现数据。语义web需要通过一种语言来形式化的描述web文档中术语的含义。这种语言称为互联网本体语言(WebOntology Language，OWL)，OWL是由W3C提出的一种用于对web本体进行语义描述的本体语言。OWL的本体定义中大体包含个体(Individual)、属性(Property)和类(Class)。

类是对某一种类型个体的抽象。例如，Person类是领域中全部人的个体的抽象。类可以通过继承关系来组织成层次型结构，子类是父类中的特殊情况，例如Person类和Professor类，Professor类是Person类的一个子类，这就说明所有的教授都是人，所有Professor类的成员都是Person类的成员，如果某个人是Professor那么他也是Person。

属性将个体关联到个体或者具体的数据值。例如，属性hasChild，hasRelative，hasSibling和hasAge。其中前面三个是将Person类的实例关联到它的另一个实例，也就是个体对象，而后面的hasAge则是将Person类的实例关联到一个具体的年龄数字。根据是将个体关联到个体还是将个体关联到具体的数据值，从现实世界中可以抽象得到两种类型的属性：一种是对象属性(ObjectProperty)，另一种称为数据类型属性(DataTypeProperty)。前者的取值是一个对象，打个比方说，Parent类的属性hasSon的取值就只能是Son，而Son也是Person类的实例。Professor类的属性hasEmployer一般可以取为某个学校，而学校就是一个对象类型，它拥有对象所能拥有的一些性质。数据类型属性的取值范围是RDF Literal或者是标准XML Schema数据类型中定义的那些简单的数据类型，如字符串，整数，URL等等。

个体是类的实例，而属性则可以用来将一个个体关联到另一个个体。例如，一个名叫Marco的个体可以是Person类的实例，而属性hasEmployer则可以将其关联到StanfordUniversity。值得注意的是，标准OWL并不像Protégé中定义的那样，在OWL中一个个体可以拥有多个不同的名称，这也更加符合现实世界多样性的特征。例如“北京大学”、“北大”和“京师大学堂”很可能都对应同一所大学。

由上述可见，OWL通过使用类、属性和实例的方式可以描述现实世界。基于此，可以采用OWL来描述现实世界中的各种服务。

进一步，基于服务的互联网本体语言(Ontology Web Language forServices,OWL-S)是web服务的本体语言；它基于web服务和语义web，构建在OWL的基础之上。OWL-S包括三个组件：服务简介(Service Profile)，服务模型(Service Model)和服务绑定关系(Service Grounding)。

Service Profile描述服务是做什么的等基本信息，包含服务名称，服务描述和分类信息，服务的输入(I)、输出(O)、前置条件(P)和效果(E)，还有服务所包含的控制流程等等，这里所说的前置条件是指服务执行时所需要满足的一些基本的外在条件，如订书服务BookService中的库存量大于零。

Service Grounding描述如何访问服务的具体细节。典型的ServiceGrounding会指定一种通信协议、消息格式和其他与特定服务相关的具体信息，包括端口数量等等。此外，Service Grounding还必须明确指明ServiceModel中所声明的输入和输出等参数的交换数据元素的方式。在与服务进行交互时需要知道该服务的一些描述信息，而一个Service Grounding可以看做是对这些信息的一个从抽象到具体的映射，例如，原子流程的输入和输出参数。在OWL-S中，Service Profile和Service Model可以被看做是服务的抽象表示，而Service Grounding则处理服务的具体规范。

Service Process也即Service Model，描述服务具体是如何工作的，其中所包含的流程可分为三类：原子流程(AtomicProcess)，复合流程(CompositeProcess)，和简单流程(SimpleProcess)。其中，AtomicProcess表示原子流程，也就是说其所代表的操作无法再继续分解为更为细的操作。而CompositeProcess是由一系列原子流程按照一定的组织方式组合而成，这种组织方式被抽象为以下9中语句，Sequence，If-Then-Else，Choice，AnyOrder，Split，SplitJoin，UnOrdered，RepeatUntil，RepeatWhile。其中每一种语句都有其自身的组成方式。

基于上述，本发明可以采用互联网本体语言，如OWL-S对服务进行描述，然后将描述结果存储到服务数据库中。则预先构建服务数据库的过程如下：

采用互联网本体语言，如OWL-S对已注册的服务进行描述，以生成服务对应的互联网本体语言文档；对服务对应的互联网本体语言文档进行解析，以获取服务简介、服务模型和服务绑定关系；将服务简介、服务模型和服务绑定关系存储到服务数据库中。其中，服务简介、服务模型和服务绑定关系代表着服务。

另外，基于OWL-S对服务的描述，可以方便服务发布方发布自己带有语义的服务。例如，机场(服务发布方)可以采用OWL-S对自己的购票、值机和登机等服务进行描述，然后发布自己的购票，值机和登机等服务，方便走进机场的用户智能的使用。

基于上述OWL-S，一种根据目标需求的描述信息，将目标需求分解为至少一个子需求的方式具体包括：

将目标需求的描述信息转换成目标需求对应的互联网本体语言文档；然后采用面向目标的需求语言(Goal-oriented Requirement Language，GRL)模型对目标需求对应的互联网本体语言文档进行分解，从而获得至少一个子需求。

其中，GRL是一种用于支持面向目标的模型和推理需求的语言，尤其适用于处理非功能性的需求。它提供一系列构件用于描述需求流程中的众多种类型的概念。这些概念大体上分为三类：内部元素，内部关系和角色。其中，内部元素有目标，任务，软目标和资源。

目标(Goal)：是参与者想要达到的事物的条件或者状态。它既可以是业务目标又可以是系统目标，业务目标是个人或者组织期望达到的业务状态，而系统目标则表示目标系统所要实现的目标，它通常用来描述目标信息系统的功能性需求。

任务(Task)：任务指定了处理问题的特定方式。一个任务被指定为另一个高层次任务的某个组件时，也就相当于为高层次任务制定了一种实施步骤。

资源(Resource)：是一个物理的或者信息的实体，我们通常考虑的是它是否可得。

软目标(Softgoal)：是指所参与到系统中的角色想要达到的事物的条件或者状态。它和上述目标不同的是，没有一个清晰的规范来判断条件是否满足，而只能靠开发者主观的判断或者解释。

信任(Belief)：被用于表示设计原理，它使得领域特性在制定决策的过程中发挥了良好的作用，因此也就促进了后续系统的检阅和修改，增强了可追溯性。

手段-目的(Means-ends)：一种内部关系，它用于描述目标实际是如何实现的。每一个任务都可以实现目标。通常情况下，每一个任务对于软目标来说具有不同的影响，这种影响的异同便可以作为评估和选择任务的标准。

分解(Decomposition)：一种内部关系，它指明了完成任务所需要满足的其他前置条件。在GRL中，只有任务才是可分解的。

贡献(Contribution)：一种内部关系，它描述了软目标，任务，信任或者链接之间的贡献关系。Contribution包括构成(Make)、帮助(Help)和伤害(Hurt)三种贡献类型。

如图2所示，是一个具体的目标需求分解实例。在图2中，目标需求AU分解成了S和可用性U两个子需求，并且这两个子需求对目标需求的Contribution都是Help；其中，子需求S又分解成了对其具有Make作用的子需求RP，该子需求是一任务；子需求U又分解成了子需求RP和子需求AQ。子需求RP对子需求U具有Hurt作用；子需求AQ对子需求U具有Help作用。其中，AU，S和U都是软目标。

如前所述，用户的目标需求被进一步分解为各个子需求。为了便于后续为子需求动态匹配服务，可以将这些子需求存储起来。具体的，可以将每个子需求作为一个GRL节点，被存储成一个GRL表，记为节点元素信息表；子需求之间的关系被存储成一个GRL表，记为节点关系表。每个GRL表的名称可以以grl开头，但不限于此。

基于上述，在为子需求匹配服务列表的过程中，为了使得匹配过程更加智能高效，本发明采用一种基于本体树的匹配方法。预先对现实世界中的本体信息进行推理，构建出本体之间的树形关系，记为本体树；该本体树包括了现实世界中几乎所有的本体以及本体之间的包含关系。该本体树具体可由领域专家来构建，本发明可以直接拿来使用。该匹配方法具体包括：

将服务数据库中服务包括的本体在本体树上进行映射，以获得服务包括的本体在本体树上的位置；例如，可以通过推理引擎，例如Pellet对服务数据库中服务包括的本体进行推理，以确定服务包括的本体在本体树上的位置；

根据上述子需求在本体树上进行匹配，以确定子需求对应的本体在本体树上的位置；其中，子需求对应的本体是指在本体树上匹配中的本体；

根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的匹配度；

获取服务数据库中包括与子需求对应的本体的匹配度大于匹配度阈值的本体的服务，以形成子需求对应的服务列表。

值得说明的是，若子需求对应的服务列表包括多个服务，则可以根据子需求对应的本体与服务包括的本体之间的匹配度，对服务列表中的多个服务进行排序。

上述根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的匹配度的一种实施方式包括：

根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的距离及包含关系；根据子需求对应的本体与服务包括的本体之间的距离及包含关系，确定子需求对应的本体与服务包括的本体之间的匹配度；

可选的，为了简化计算过程，提高计算效率，可以对上述匹配度进行量化，例如将上述匹配度量化为0到1之间的数值。则可以根据以下公式，计算子需求对应的本体与服务包括的本体之间的匹配度。

$\mathrm{dom}(A,B)=\left\{\begin{array}{cc}1& \mathrm{exact}\_\mathrm{match},\\ \frac{1}{2}+\frac{1}{e^{\left(\right||A,B||-1)}}& \mathrm{plugin}\_\mathrm{match},\\ \frac{1}{2\×e^{\left(\right||A,B||-1)}}& \mathrm{subsume}\_\mathrm{match},\\ 0& \mathrm{no}\_\mathrm{match}\end{array}\right.$

在上述公式中，用A表示子需求对应的本体，B表示服务包括的本体，则||A,B||表示子需求对应的本体与服务包括的本体之间的距离；dom(A,B)表示子需求对应的本体与服务包括的本体之间的匹配度。

在上述公式中，exact_match表示子需求对应的本体与服务包括的本体之间的距离为0，且子需求对应的本体是服务包括的本体的情况，或者表示子需求对应的本体与服务包括的本体之间的距离为0，且服务包括的本体是子需求对应的本体的直接子类的情况。简单来说，这种情况是指A＝B，也即A和B在本体树上的位置相同，且A是B或者B是A的直接子类的情况，将A对B的这种关系称为精确匹配(EXACT)。

在上述公式中，plugin_match表示服务包括的本体包含子需求对应的本体，且子需求对应的本体与服务包括的本体之间的距离大于等于2的情况。简单来说，这种情况是指B包含A，也即A是B的子节点但不是直接子节点，将A对B的这种关系插入式匹配(PLUGIN)。

在上述公式中，subsume_match表示子需求对应的本体包含服务包括的本体，且子需求对应的本体与服务包括的本体之间的距离大于等于1的情况。简单来说，这种情况是指A包含B，即A是B的祖先节点，将A对B的这种关系称为包含匹配(SUBSUME)。

在上述公式中，no_match表示除exact_match、plugin_match和subsume_match表示的情况之外的其它情况，这种情况可称为无匹配(NO MATCH)。

如图3所示，是一种简单的本体树，该本体树自下而上依次包括以下本体：教授(Professor)、研究员(Researcher)、系(Faculty)、编程人员(Programmer)、人(Person)、事务(Thing)。结合图3对上述几种匹配类型进行说明。在图3中，Professor对Person的关系为插入式匹配；Person对Researcher的关系即为包含匹配，并且Person对Faculty的关系也为包含匹配；Faculty对Programmer的关系为无匹配。

在上述计算匹配度的公式中，事先规定精确匹配与无匹配的匹配度值分别为整数1和0，而插入式匹配和包含匹配的匹配度需要根据两个本体在本体树上的距离，例如最短路径距离来确定；在上述计算匹配度的公式中，插入式匹配的匹配度在开区间0.5到1内，而包含匹配的匹配度在开区间0到0.5内。由此可见，插入式匹配总是比包含匹配拥有更高的匹配度，因为插入式匹配所表现的是更加具体的语义关系，它往往能够满足相对其他稍宽泛一些的语义需求。

在一可选实施方式中，可以基于用户当前所处的位置信息，向用户推荐服务。具体的，在向用户返回每个子需求对应的服务列表之前，可以根据用户当前所处的位置信息和服务列表中服务的位置信息，对服务列表中的服务进行排序。例如，可以将距离用户当前所处的位置信息最近的服务排在最前面，以便于用户优先选择距离最近的服务，提高用户获取并使用服务的效率。

其中，在使用用户当前所处的位置信息之前，需要先获取用户当前所处的位置信息。获取用户当前所处的位置信息的方式可以有多种，例如通过GPS定位信号，计算用户当前所处的位置信息，或者可以通过基站估计用户当前所处的位置信息，或者还可以通过采集用户终端周围的无线信号，如WIFI信号等来估计用户当前所处的位置信息。

由上述可见，通过采集用户当前所处的位置信息，将用户当前所处的位置信息与服务推荐相结合，可以基于用户的位置向用户推荐服务。

例如，采用本发明技术方案，机场乘客在机场可以查询附近的服务，并发现机场发布的购票服务，然后使用机场的购票服务进行购票。进一步，机场乘客使用了机场的购票服务后，本发明可以推断服务的下一步即机场发布的值机服务，并推荐给用户。用户使用了值机服务后，本发明可以继续推断服务的下一步即机场发布的登机服务，推荐给用户。用户使用登机服务后整个流程结束。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

图4为本发明一实施例提供的服务推荐装置的结构示意图。如图4所示，该装置包括：第一获取模块41、分解模块42、第二获取模块42和推荐模块44。

第一获取模块41，用于获取用户输入的目标需求的描述信息。

分解模块42，用于根据第一获取模块41获取的目标需求的描述信息，将目标需求分解为至少一个子需求。

第二获取模块43，用于获取分解模块42分解出的至少一个子需求中每个子需求对应的服务列表。

推荐模块44，用于向用户返回第二获取模块43获取的每个子需求对应的服务列表。

在一可选实施方式中，分解模块42具体用于：

将目标需求的描述信息转换成目标需求对应的互联网本体语言文档；

按照GRL模型对目标需求对应的互联网本体语言文档进行分解，以获得至少一个子需求。

在一可选实施方式中，第二获取模块43具体用于：

根据每个子需求在服务数据库中进行匹配，以获得每个子需求对应的服务列表，服务数据库包括已注册的服务的信息。

在一可选实施方式中，第二获取模块43进一步具体用于：

将服务数据库中服务包括的本体在预设的本体树上进行映射，以获得服务包括的本体在本体树上的位置；

根据子需求在本体树上进行匹配，以确定子需求对应的本体在本体树上的位置；

根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的匹配度；

获取服务数据库中包括与子需求对应的本体的匹配度大于匹配度阈值的本体的服务，以形成子需求对应的服务列表。

在一可选实施方式中，第二获取模块43在根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的匹配度时，进一步具体用于：

根据子需求对应的本体在本体树上的位置以及服务包括的本体在本体树上的位置，确定子需求对应的本体与服务包括的本体之间的距离及包含关系；

根据子需求对应的本体与服务包括的本体之间的距离及包含关系，确定子需求对应的本体与服务包括的本体之间的匹配度。

在一可选实施方式中，第二获取模块43在根据子需求对应的本体与服务包括的本体之间的距离及包含关系，确定子需求对应的本体与服务包括的本体之间的匹配度时，进一步具体用于：

根据公式 $\mathrm{dom}(A,B)=\left\{\begin{array}{cc}1& \mathrm{exact}\_\mathrm{match},\\ \frac{1}{2}+\frac{1}{e^{\left(\right||A,B||-1)}}& \mathrm{plugin}\_\mathrm{match},\\ \frac{1}{2\×e^{\left(\right||A,B||-1)}}& \mathrm{subsume}\_\mathrm{match},\\ 0& \mathrm{no}\_\mathrm{match}\end{array}\right.,$ 确定子需求对应的本体与服务包括的本体之间的匹配度；

其中，dom(A,B)表示子需求对应的本体与服务包括的本体之间的匹配度；

||A,B||表示子需求对应的本体与服务包括的本体之间的距离；

exact_match表示子需求对应的本体与服务包括的本体之间的距离为0，且子需求对应的本体是服务包括的本体的情况，或者表示子需求对应的本体与服务包括的本体之间的距离为0，且服务包括的本体是子需求对应的本体的直接子类的情况；

plugin_match表示服务包括的本体包含子需求对应的本体，且子需求对应的本体与服务包括的本体之间的距离大于等于2的情况；

subsume_match表示子需求对应的本体包含服务包括的本体，且子需求对应的本体与服务包括的本体之间的距离大于等于1的情况

no_match表示除exact_match、plugin_match和subsume_match表示的情况之外的其它情况。

在一可选实施方式中，如图5所示，该服务推荐装置还可以包括：构建模块45。

构建模块45，用于在使用服务数据库之前，构建服务数据库。构建模块45构建服务数据库的过程，具体为：

采用互联网本体语言对服务进行描述，以生成服务对应的互联网本体语言文档；

对服务对应的互联网本体语言文档进行解析，以获取服务简介、服务模型和服务绑定关系；

将服务简介、服务模型和服务绑定关系存储到服务数据库中。

在一可选实施方式中，如图5所示，该服务推荐装置还可以包括：排序模块46。

排序模块46，用于在推荐模块44向用户返回每个子需求对应的服务列表之前，根据用户当前所处的位置信息和服务列表中服务的位置信息，对服务列表中的服务进行排序。基于此，推荐模块44向用户返回的是根据用户当前所处的位置信息进行排序后的服务列表，实现基于用户位置向用户推荐服务的目的。

本实施例提供的服务推荐装置，可以获取用户输入的目标需求的描述信息，根据目标需求的描述信息，将目标需求拆分为至少一个子需求，进而获取每个子需求对应的服务列表，向用户返回每个子需求对应的服务列表，以供用户选择使用的服务，实现了向用户直接推送服务的目的，由于直接推送给用户的是服务，而不是服务提供商的信息，有利于提高用户使用服务的效率，满足用户的应用需求。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (16)

1.一种服务推荐方法，其特征在于，包括：

获取用户输入的目标需求的描述信息；

根据所述目标需求的描述信息，将所述目标需求分解为至少一个子需求；

获取所述至少一个子需求中每个子需求对应的服务列表；

向所述用户返回所述每个子需求对应的服务列表。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标需求的描述信息，将所述目标需求分解为至少一个子需求，包括：

将所述目标需求的描述信息转换成所述目标需求对应的互联网本体语言文档；

按照面向目标的需求语言GRL模型对所述目标需求对应的互联网本体语言文档进行分解，以获得所述至少一个子需求。

3.根据权利要求1所述的方法，其特征在于，所述获取所述至少一个子需求中每个子需求对应的服务列表，包括：

根据所述每个子需求在服务数据库中进行匹配，以获得所述每个子需求对应的服务列表，所述服务数据库包括已注册的服务的信息。

4.根据权利要求3所述的方法，其特征在于，所述根据所述每个子需求在服务数据库中进行匹配，以获得所述每个子需求对应的服务列表，包括：

将所述服务数据库中服务包括的本体在预设的本体树上进行映射，以获得所述服务包括的本体在所述本体树上的位置；

根据所述子需求在所述本体树上进行匹配，以确定所述子需求对应的本体在所述本体树上的位置；

根据所述子需求对应的本体在所述本体树上的位置以及所述服务包括的本体在所述本体树上的位置，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度；

获取所述服务数据库中包括与所述子需求对应的本体的匹配度大于匹配度阈值的本体的服务，以形成所述子需求对应的服务列表。

5.根据权利要求4所述的方法，其特征在于，所述根据所述子需求对应的本体在所述本体树上的位置以及所述服务包括的本体在所述本体树上的位置，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度，包括：

根据所述子需求对应的本体在所述本体树上的位置以及所述服务包括的本体在所述本体树上的位置，确定所述子需求对应的本体与所述服务包括的本体之间的距离及包含关系；

根据所述子需求对应的本体与所述服务包括的本体之间的距离及包含关系，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度。

6.根据权利要求5所述的方法，其特征在于，所述根据所述子需求对应的本体与所述服务包括的本体之间的距离及包含关系，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度，包括：

根据公式 $\mathrm{dom}(A,B)=\left\{\begin{array}{cc}1& \mathrm{exact}\_\mathrm{match},\\ \frac{1}{2}+\frac{1}{e^{\left(\right||A,B||-1)}}& \mathrm{plugin}\_\mathrm{match},\\ \frac{1}{2\×e^{\left(\right||A,B||-1)}}& \mathrm{subsume}\_\mathrm{match},\\ 0& \mathrm{no}\_\mathrm{match}\end{array}\right.,$ 确定所述子需求对应的本体与所述服务包括的本体之间的匹配度；

其中，dom(A,B)表示所述子需求对应的本体与所述服务包括的本体之间的匹配度；

||A,B||表示所述子需求对应的本体与所述服务包括的本体之间的距离；

exact_match表示所述子需求对应的本体与所述服务包括的本体之间的距离为0，且所述子需求对应的本体是所述服务包括的本体的情况，或者表示所述子需求对应的本体与所述服务包括的本体之间的距离为0，且所述服务包括的本体是所述子需求对应的本体的直接子类的情况；

plugin_match表示所述服务包括的本体包含所述子需求对应的本体，且所述子需求对应的本体与所述服务包括的本体之间的距离大于等于2的情况；

subsume_match表示所述子需求对应的本体包含所述服务包括的本体，且所述子需求对应的本体与所述服务包括的本体之间的距离大于等于1的情况

no_match表示除exact_match、plugin_match和subsume_match表示的情况之外的其它情况。

7.根据权利要求3所述的方法，其特征在于，所述根据所述每个子需求在服务数据库中进行匹配，以获得所述每个子需求对应的服务列表之前，还包括：

采用互联网本体语言对所述服务进行描述，以生成所述服务对应的互联网本体语言文档；

对所述服务对应的互联网本体语言文档进行解析，以获取服务简介、服务模型和服务绑定关系；

将所述服务简介、服务模型和服务绑定关系存储到所述服务数据库中。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述向所述用户返回所述每个子需求对应的服务列表之前，还包括：

根据所述用户当前所处的位置信息和所述服务列表中服务的位置信息，对所述服务列表中的服务进行排序。

9.一种服务推荐装置，其特征在于，包括：

第一获取模块，用于获取用户输入的目标需求的描述信息；

分解模块，用于根据所述目标需求的描述信息，将所述目标需求分解为至少一个子需求；

第二获取模块，用于获取所述至少一个子需求中每个子需求对应的服务列表；

推荐模块，用于向所述用户返回所述每个子需求对应的服务列表。

10.根据权利要求9所述的装置，其特征在于，所述分解模块具体用于：

将所述目标需求的描述信息转换成所述目标需求对应的互联网本体语言文档；

按照面向目标的需求语言GRL模型对所述目标需求对应的互联网本体语言文档进行分解，以获得所述至少一个子需求。

11.根据权利要求9所述的装置，其特征在于，所述第二获取模块具体用于：

根据所述每个子需求在服务数据库中进行匹配，以获得所述每个子需求对应的服务列表，所述服务数据库包括已注册的服务的信息。

12.根据权利要求11所述的装置，其特征在于，所述第二获取模块具体用于：

将所述服务数据库中服务包括的本体在预设的本体树上进行映射，以获得所述服务包括的本体在所述本体树上的位置；

根据所述子需求在所述本体树上进行匹配，以确定所述子需求对应的本体在所述本体树上的位置；

根据所述子需求对应的本体在所述本体树上的位置以及所述服务包括的本体在所述本体树上的位置，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度；

获取所述服务数据库中包括与所述子需求对应的本体的匹配度大于匹配度阈值的本体的服务，以形成所述子需求对应的服务列表。

13.根据权利要求12所述的装置，其特征在于，所述第二获取模块具体用于：

根据所述子需求对应的本体在所述本体树上的位置以及所述服务包括的本体在所述本体树上的位置，确定所述子需求对应的本体与所述服务包括的本体之间的距离及包含关系；

根据所述子需求对应的本体与所述服务包括的本体之间的距离及包含关系，确定所述子需求对应的本体与所述服务包括的本体之间的匹配度。

14.根据权利要求13所述的装置，其特征在于，所述第二获取模块具体用于：

根据公式 $\mathrm{dom}(A,B)=\left\{\begin{array}{cc}1& \mathrm{exact}\_\mathrm{match},\\ \frac{1}{2}+\frac{1}{e^{\left(\right||A,B||-1)}}& \mathrm{plugin}\_\mathrm{match},\\ \frac{1}{2\×e^{\left(\right||A,B||-1)}}& \mathrm{subsume}\_\mathrm{match},\\ 0& \mathrm{no}\_\mathrm{match}\end{array}\right.,$ 确定所述子需求对应的本体与所述服务包括的本体之间的匹配度；

其中，dom(A,B)表示所述子需求对应的本体与所述服务包括的本体之间的匹配度；

||A,B||表示所述子需求对应的本体与所述服务包括的本体之间的距离；

exact_match表示所述子需求对应的本体与所述服务包括的本体之间的距离为0，且所述子需求对应的本体是所述服务包括的本体的情况，或者表示所述子需求对应的本体与所述服务包括的本体之间的距离为0，且所述服务包括的本体是所述子需求对应的本体的直接子类的情况；

plugin_match表示所述服务包括的本体包含所述子需求对应的本体，且所述子需求对应的本体与所述服务包括的本体之间的距离大于等于2的情况；

subsume_match表示所述子需求对应的本体包含所述服务包括的本体，且所述子需求对应的本体与所述服务包括的本体之间的距离大于等于1的情况

no_match表示除exact_match、plugin_match和subsume_match表示的情况之外的其它情况。

15.根据权利要求11所述的装置，其特征在于，还包括：构建模块，用于：

采用互联网本体语言对所述服务进行描述，以生成所述服务对应的互联网本体语言文档；

对所述服务对应的互联网本体语言文档进行解析，以获取服务简介、服务模型和服务绑定关系；

将所述服务简介、服务模型和服务绑定关系存储到所述服务数据库中。

16.根据权利要求9-15任一项所述的装置，其特征在于，还包括：

排序模块，用于根据所述用户当前所处的位置信息和所述服务列表中服务的位置信息，对所述服务列表中的服务进行排序。