CN111788565A - 分布式语义数据的语义操作和推理支持 - Google Patents

Abstract

方法、系统和装置，解决与语义推理操作相关的问题。能够基于应用需求定义不同的定制或用户定义的规则，即使这些规则基于相同的初始事实，也会导致不同的推断事实。

Description

分布式语义数据的语义操作和推理支持

相关申请的交叉引用

本申请要求于2018年2月27日提交的标题为“Semantic Operations andReasoning Support Over Distributed Semantic Data”的美国临时专利申请No.62/635,827的权益，其内容在此通过引用并入本文。

背景技术

语义Web是万维网联盟(W3C)通过标准对Web的扩展。这些标准促进Web上的公共数据格式和交换协议，最基本的是资源描述框架(RDF)。语义Web涉及以专门为数据设计的以下语言发布：资源描述框架(RDF)、Web本体语言(OWL)以及可扩展标记语言(XML)。这些技术组合，以提供经由链接数据的网来补充或替换Web文档内容的描述。因此，内容可以表现为存储在Web可访问数据库中的描述性数据，或者表现为文档内的标记，特别地用散布在XML中的可扩展HTML(XHTML)或者更常见的是纯粹用XML，其中布局或渲染提示分开存储。

语义Web堆栈说明由W3C指定的语义Web的体系架构，如图1中所示。部件的功能和关系可以总结如下。XML为文档内的内容结构提供元素语法，但没有将语义与其中包含的内容的含义相关联。在大多数情况下，XML目前不是语义Web技术的必要部件，因为存在替代语法，诸如Turtle。Turtle是实际上的标准，但尚未通过正式的标准化过程。

XML Schema是一种用于提供和限制XML文档内包含的元素的结构和内容的语言。

RDF是用于表达数据模型的简单语言，其以主语-谓语-宾语(例如，S-P-O三元组或RDF三元组)的形式提及对象(“web资源”)及其关系。基于RDF的模型可以用各种语法表示，例如RDF/XML、N3、Turtle和RDFa。RDF是语义Web的基本标准。

RDF图是有向图，其中边表示RDF三元组的“谓语”，而图节点表示RDF三元组的“主语”或“宾语”。换句话说，如RDF三元组中描述的链接结构形成这种有向RDF图。

RDF Schema(RDFS)扩展了RDF，并且是用于描述基于RDF的资源的特性和类的词汇表，具有这些特性和类的通用层次结构的语义。

OWL添加了更多用于描述特性和类的词汇：其中，包括类之间的关系(例如，不相交)、基数(例如“确切地一个”)、相等性、更丰富的特性类型、特性的特征(例如，对称性)和枚举类。

SPARQL是用于语义web数据源的协议和查询语言，以在Web上或在RDF存储装置(例如，语义图存储装置)中查询和操纵RDF图内容(例如，RDF三元组)。

·SPARQL 1.1Query，用于RDF图的查询语言，可以用于表达跨不同数据源的查询，无论数据是本机存储为RDF还是经由中间件被视为RDF。SPARQL可以包括查询必需和可选图模式及其结合和分离的能力中的一个或多个。SPARQL还支持聚合、子查询、求反、通过表达式创建值、可扩展值测试以及通过源RDF图约束查询。SPARQL查询的结果可以是结果集或RDF图。

·SPARQL 1.1Update，用于RDF图的更新语言。它使用从用于RDF的SPARQL查询语言导出的语法。对语义图存储装置中的图的集合执行更新操作。提供操作以在语义图存储装置中更新、创建和移除RDF图。

规则是计算机科学中的概念：它是IF-THEN构造。如果在一些数据集中可检查的某个条件(IF部分)成立，那么处理结论(THEN部分)。虽然本体可以描述域知识，但是规则是描述有时使用OWL中使用的描述逻辑难以或无法直接描述的某些知识或关系的另一种方法。规则也可以用于语义推断/推理，例如，用户可以定义他们自己的推理规则。

RIF是规则交换格式。但是，在计算机科学和逻辑编程社区中，有两种不同但密切相关的方式来理解规则。其一与计算机程序中指令的构思紧密相关：如果某个条件成立，那么执行某个动作。此类规则常常被称为产生式规则。产生式规则的示例是“如果客户已经飞行超过100000英里，那么将其升级为金卡会员身份”。

可替代地，人们可以认为规则是陈述关于世界的事实。这些规则常常被称为声明性规则，被理解为形式为“如果P，那么Q”的句子。声明性规则的示例是“如果某人当前是美利坚合众国的总统，那么他或她目前的住所就是白宫。”

有许多规则语言，包括SILK、OntoBroker、Eye、VampirePrime、N3-Logic和SWRL(声明性规则语言)；以及Jess、Drools、IBM ILog和Oracle业务规则(产生式规则语言)。许多语言结合了声明性和产生式规则语言两者的特征。如果人们想要集成规则集，或者将信息从一个规则集导入另一个规则集，那么不同语言的大量规则集会造成困难。本文考虑的是规则引擎如何可以与不同语言的规则集一起工作。

W3C规则交换格式(RIF)是被开发以促进规则集集成和合成的标准。它包括表示具有各种特征的规则语言的相互关联的方言(诸如RIF核心、RIF基本逻辑方言(BLD)、RIF产生式规则方言(PRD)等)的集合。例如，下面讨论的示例基于RIF核心(这是最基本的一个)。RIF方言BLD通过允许逻辑定义的功能来扩展RIF核心。RIF方言PRD通过允许对规则进行优先级排序、求反和知识库修改的明确声明来扩展RIF核心。

以下是RIF的示例。这个示例涉及关于跨语义Web的电影和剧本的数据的集成。例如，假定某人想要将关于来自IMDb(互联网电影数据库(在http://imdb.com))与DBpedia(在http://dbpedia.org)的电影的数据组合在一起。两种资源都包含关于演员在电影的演员表中的事实，但是DBpedia将这些事实表示为二进制关系(又称为谓语或RDF特性)。

例如，在DBpedia中，人们可以表达演员在电影的演员表中的事实：

·starring(？Film？Actor)

我们在这里使用“？”前缀的变量作为占位符。在这个示例中使用的变量名称对人类读者有意义，但对机器没有意义。这些变量名称旨在向读者传达DBpedia主演关系的第一个自变量是电影，并且第二个是在电影中主演的演员。

但是，在IMDb中，没有类似的关系。相反，可以陈述关于演员扮演角色的以下形式的事实：

·playsRole(？Actor？Role)

并且可以陈述关于电影中角色(人物)的以下形式的事实：

·roleInFilm(？Role？Film)

因此，例如，在DBpedia中，将表示作为事实的Vivien Leigh在A Streetcar NamedDesire的演员表中的信息。

·starring(Streetcar VivienLeigh)

但是，在IMDb中，表示两条信息，即，Vivien Leigh扮演Blanche DuBois的角色：

·playsRole(VivienLeigh Blanche DuBois)

并且Blanche DuBois是A Streetcar Named Desire中的人物：

·roleInFilm(Blanche DuBois Streetcar)

组合这些数据存在挑战：不仅两个数据源(IMDb和DBpedia)使用不同的词汇(关系名称为starring、playsRole、roleInFilm)，而且结构也不同。为了组合这些数据，我们本质上想说类似以下规则的内容：如果IMDb数据库中有两个事实，比如说演员扮演角色/人物， 并且该人物在电影中，那么在DBpedia数据库中只有一个事实，比如说演员在电影中。可以将该上面提到的规则写为RIF规则，如下(粗体字是RIF定义的关键词，并且有关RIF规范的更多细节可以在RIF Primer，https：//www.w3.org/2005/rules/wiki/Primer中找到)：

语义推理。一般而言，语义推理或推断意味着导出未在知识库中明确表述的事实。换句话说，它是一种从现有知识库中导出新的隐含知识的机制。示例：要考虑的数据集(作为初始事实/知识)可以包括关系(Flipper是海豚–关于实例的事实)。注意事实和知识可以在本文中互换使用。本体可以声明“每个海豚也是哺乳动物–关于概念的事实”。如果推理规则说明“IF A是类B的实例并且B是类C的子类，THEN A也是类C的实例”，那么通过根据推理处理对初始事实应用这个规则，可以推断出新的语句：Flipper是哺乳动物，这是基于推理而得出的隐含知识/事实，但是这并不是初始事实的一部分，[W3C Semantic Inference，www.w3.org/standards/semanticweb/inference]。

从以上示例可以看出，语义推理涉及几个关键概念：

1.知识/事实库(事实和知识将在本文中互换使用)

2.语义推理规则以及

3.推断事实。

以下各部分给出了关于知识库和语义规则的更多细节。为了实现以上示例的语义推理处理，可以使用语义推理器(Semantic Reasoner，https://en.wikipedia.org/wiki/Semantic_reasoner)。通常，语义推理器(推理引擎、规则引擎，或简称为推理器)是一款能够使用推理规则集从断言的事实集中推断出逻辑后果的软件。有一些开源语义推理器，并且后面的部分将给出关于由Apache Jena提供的示例推理器的更多细节(https://jena.apache.org/documentation/inference/)。此外，语义推理或推断通常是指导出附加信息的抽象过程，而语义推理器是指执行推理任务的具体代码对象。

知识库(KB)是用于存储由计算机系统使用的复杂结构化和非结构化信息的技术[https://en.wikipedia.org/wiki/Abox][TBox，https://en.wikipedia.org/wiki/Tbox]。KB的构成具有以下形式：

知识库＝ABox+TBox

术语“ABox”和“TBox”被用于描述两种不同类型的语句/事实。TBox语句根据受控的词汇表(例如，类和特性的集合(例如，方案或本体定义))描述系统。ABox是关于该词汇表的TBox兼容语句。

例如，ABox语句通常具有以下形式：

A是B的实例或者John是人

相比之下，TBox语句通常具有以下形式，诸如：

所有学生均为人或者

人有两种类型：学生和教师(例如，学生和教师是人的子类)

总之，TBox语句与面向对象的类(例如，方案或本体定义)相关联，而ABox语句与那些类的实例相关联。在前面的示例中，事实语句“Flipper是海豚”是Abox语句，而“每个海豚也是哺乳动物”是TBox语句。

蕴含是在某些条件下一个语句的真实性确保第二个语句的真实性的原理。W3C定义了不同的标准蕴含机制，例如RDF蕴含、RDF Schema蕴含、OWL 2基于RDF的语义蕴含等。特别地，每种蕴含机制都定义了蕴含规则集[https://www.w3.org/TR/sparql11-entailment/]并且以下是由RDFS蕴含机制定义的两个推理规则(规则7和规则11)[https://www.w3.org/TR/rdf-mt/#rules]：

规则7：IF aaa rdfs:subProperty of bbb&&uuu aaa yyy,THEN uuu bbb yyy

这意味着：如果aaa是bbb的子特性，并且uuu的aaa特性具有yyy的值，那么uuu的bbb特性也具有yyy的值(在此，“aaa”、“uuu”、“bbb”只是变量名)。

规则11：IF uuu rdfs:subClassOf vvv and vvv rdfs:subClassOf x,THEN uuurdfs:subClassOf x

这意味着：如果uuu是vvv的子类，并且vvv是x的子类，那么uuu也是x的子类。

当启动语义推理工具中的语义推理器时，常常要求指定将要实现哪个蕴含机制。例如，语义推理器实例A可以是“RDFS推理器”，它将支持由RDFS蕴含机制定义的推理规则。例如，假设我们具有以下初始事实(以RDF三元组描述)：

通过将那些事实输入到语义推理器实例A中，可以使用如上介绍的RDFS规则11导出以下推断事实：

·ex:dog rdfs:subClassOf ex:animal

语义推理工具示例：Jena推断支持。Jena推断被设计为允许将一系列推断引擎或推理器插入Jena。此类引擎被用于导出从一些现有/基本事实连同任何可选的本体信息和与推理器相关联的规则蕴含的附加RDF断言/事实。

Jena分布支持许多预定义的推理器，诸如RDFS推理器或OWL推理器(实现分别由前一部分中介绍的对应蕴含机制定义的推理规则集)，以及作为支持“用户定义的”规则的基于通用规则的推理器的通用规则推理器。

下面的代码示例说明了如何使用Jena API进行语义推理任务：让我们首先创建Jena模型(在第3行中调用rdfsExample，实际上是这个示例中的“初始事实”)，其中包含以下语句：特性“p”是另一个特性“q”的子特性(如第6行中所定义的)并且我们有资源“a”，其“p”的值为“foo”(如第7行中所定义的)：

1.String NS＝"urn:x-hp-jena:eg/"；

2.//构建平凡示例数据集

3.Model rdfsExample＝ModelFactory.createDefaultModel()；

4.Property p＝rdfsExample.createProperty(NS,"p")；

5.Property q＝rdfsExample.createProperty(NS,"q")；

6.rdfsExample.add(p,RDFS.subPropertyOf,q)；

7.rdfsExample.createResource(NS+"a").addProperty(p,"foo")；

现在，所有初始事实都存储在变量rdfsExample中。然后，我们可以用以下代码创建对初始事实执行RDFS推断的推断模型：

8.InfModel inf＝ModelFactory.createRDFSModel(rdfsExample)；

如第8行所示，通过使用createRDFSModel()API创建RDFS推理器，并且输入是存储在变量rdfsExample中的初始事实。因而，将通过将(部分)RDFS规则集应用于存储在rdfsExample中的事实来执行语义推理处理，并将推断出的事实存储在变量inf中。

我们现在可以检查存储在变量inf中的推断事实。例如，我们想知道资源a的特性q的值，这可以用以下代码实现：

9.Resource a＝inf.getResource(NS+"a")；

10.System.out.println("Statement:"+a.getProperty(q))；

输出将是：

11.Statement:[urn:x-hp-jena:eg/a,urn:x-hp-jena:eg/q,Literal<foo>]

如第11行所示，资源a的特性q的值为“foo”，其为基于RDFS推理规则之一推断出的事实：IF aaa rdfs:subPropertytyof bbb&&uuu aaa yyy,THEN uuu bbb yyy(RDFS蕴含规则的规则7)。推理处理如下：对于资源a，由于其特性p的值是“foo”并且p是q的子特性，因此资源a的特性q的值是“foo”。

oneM2M。正在开发的oneM2M标准定义了称为“公共服务实体(CSE)”的服务层。服务层的目的是提供可由不同“垂直”M2M系统和应用利用的“水平”服务。CSE支持四个参考点，如图2中所示。Mca参考点与应用实体(AE)接口。Mcc参考点与同一服务提供者域内的另一个CSE接口，并且Mcc的参考点与不同服务提供者域中的另一个CSE接口。Mcn参考点与底层网络服务实体(NSE)接口。NSE为CSE提供底层网络服务，诸如设备管理、位置服务和设备触发。

CSE可以包括称为“公共服务功能(CSF)”的多个逻辑功能中的一个或多个，诸如“发现”和“数据管理&储存库”。图3说明了由oneM2M定义的CSF中的一些。

oneM2M体系架构启用以下类型的节点：

应用服务节点(ASN)：ASN是包含一个CSE并且包含至少一个应用实体(AE)的节点。物理映射的示例：ASN可以驻留在M2M设备中。

应用专用节点(ADN)：ADN是包含至少一个AE并且不包含CSE的节点。oneM2M系统的场域中可以有零个或多个ADN。物理映射的示例：应用专用节点可以驻留在受约束的M2M设备中。

中间节点(MN)：MN是包含一个CSE并且包含零个或多个AE的节点。oneM2M系统的场域中可以有零个或多个MN。物理映射的示例：MN可以驻留在M2M网关中。

基础设施节点(IN)：IN是包含一个CSE并包含零个或多个AE的节点。每个oneM2M服务提供者的基础设施域中只有一个IN。IN中的CSE可以包含不适用于其它节点类型的CSE功能。物理映射的示例：IN可以驻留在M2M服务基础设施中。

非oneM2M节点(NoDN)：非oneM2M节点是不包含oneM2M实体的节点(既不是AE也不是CSE)。这些节点表示附接到oneM2M系统的设备，用于互相配合目的，包括管理。

语义注释。在oneM2M中，<semanticDescriptor>资源用于存储与资源相关的语义描述。根据本体来提供这种描述。语义信息由oneM2M系统的语义功能使用，并且也可以用于应用或CSE。一般而言，<semanticDescriptor>资源(如图4所示)是其父资源(诸如<AE>、<container>、<CSE>、<group>资源等)的语义注释。

语义过滤和资源发现。一旦启用了语义注释(例如，<semanticDescriptor>资源中的内容是其父资源的语义注释)，就可以支持语义资源发现或语义过滤。语义资源发现被用于基于<semanticDescriptor>资源的描述符属性中包含的语义描述在CSE中寻找资源。为此，已经公开了请求操作过滤器准则的附加值(例如，“semanticsFilter”过滤器)，其定义在下表1中示出。语义过滤器存储SPARQL语句(基于需求来定义发现准则/约束)，该语句将对相关的语义描述执行。“需求”(例如，请求或要求)常常是应用驱动的。例如，可能存在在地理区域中寻找由制造商A生产的所有设备的请求。可以为这个需求编写对应的SPARQL语句。语义资源发现的工作机制如下：语义资源发现是通过发送带有semanticsFilter参数的检索请求来发起的。由于整个语义描述(形成图)可以跨<semanticDescriptor>资源的集合分布，因此必须首先检索所有相关的语义描述。然后，将对那些相关的语义描述执行如语义过滤器中包括的SPARQL查询语句。如果在SPARQL处理期间可以识别出某些资源URI，那么那些资源URI将作为发现结果返回。在[oneM2M-TS-0001oneM2M功能体系架构-V3.8.0]中引用表1

表1.filterCriteria中的“semanticsFilter”条件标记

语义查询。一般而言，语义查询使得能够基于数据(诸如RDF数据)中包含的语法、语义和结构信息来检索明确和隐含导出的信息。语义查询的结果是用于回答/匹配查询的语义信息/知识。通过比较，语义资源发现的结果是识别出的资源URI的列表。作为示例，语义资源发现是找出“表示建筑物A中的温度传感器的所有资源URI”(例如，发现结果可以包括<sensor-1>和<sensor-2>的URI)，而语义查询是询问问题“建筑物A中有多少温度传感器？”(例如，由于建筑物A中有两个传感器，例如<sensor-1>和<sensor-2>，因此查询结果将为“2”)。

对于给定的语义查询，它可以对RDF三元组的集合(称为“RDF数据基础”)执行，该RDF三元组的集合可以分布在不同的语义资源(诸如<semanticDescriptor>资源)中。与语义查询相关联的“查询范围”被用于确定应当在该查询的RDF数据基础中包括哪些语义资源。

语义资源发现和语义查询都使用相同的语义过滤器来指定以SPARQL查询语言指定的查询语句。当CSE接收到包括语义过滤器的RETRIEVE(检索)请求时，如果请求中还存在“语义查询指示符”参数，那么该请求将作为语义查询被处理；否则，该请求应作为语义资源发现被处理。在语义查询过程中，给定接收到的语义查询请求及其查询范围，SPARQL查询语句应对从查询范围中的(一个或多个)语义资源收集的聚合语义信息执行并且产生的输出将是该语义查询的结果。

发明内容

由于来自事实角度(通常事实被表示为语义三元组)和推理规则角度的新问题，常规的语义推理可能无法直接在基于SL的平台的上下文中使用。从事实的角度来看，数据或事实常常被分散或分布在不同的地点(例如，现有oneM2M<semanticDescriptor>资源中的RDF三元组)。本文中公开了可以组织或集成相关“事实筒仓”以使输入(例如，事实集)准备好进行推理处理的方法、系统和装置。从推理规则的角度来看，基于服务层(SL)的平台常常被假定为是启用跨不同部分的应用的水平平台。因此，可以基于应用需求定义不同的定制或用户定义的规则，这会导致不同的推断事实(即使它们基于相同的初始事实)。

附图说明

可以从以下通过结合附图的示例给出的描述获得更详细的理解，其中：

图1图示了语义Web的示例性体系架构；

图2图示了示例性oneM2M体系架构；

图3图示了示例性oneM2M公共服务功能；

图4图示了<semanticDescriptor>资源的示例性结构；

图5图示了示例性智能设施管理用例；

图6图示了示例性语义推理部件以及利用其它语义操作的优化；

图7图示了用于FS发布的示例性CREATE操作；

图8图示了用于FS检索的示例性RETRIEVE操作；

图9图示了用于FS更新/删除的示例性UPDATE/DELETE操作；

图10图示了用于RS发布的示例性CREATE操作；

图11图示了用于RS检索的示例性RETRIEVE操作；

图12图示了用于RS更新/删除的示例性UPDATE/DELETE操作；

图13图示了由RI触发的示例性一次性推理；

图14图示了由RI触发的示例性连续推理；

图15图示了由推理支持的示例性扩充IDB；

图16图示了用于oneM2M服务层的示例性新语义推理服务CSF；

图17图示了为FS启用定义的实体的示例性oneM2M示例；

图18图示了为RS启用定义的实体的示例性oneM2M示例；

图19图示了用于个体语义推理操作中涉及的实体的示例性oneM2M示例；

图20图示了用于个体语义推理操作中涉及的实体的示例性替代示例；

图21图示了用于为在推理支持下优化语义操作定义的实体的示例性oneM2M示例；

图22图示了用于为在推理支持下优化语义操作定义的实体的示例性替代示例；

图23图示了在ETSI CIM和oneM2M之间在推理支持下的语义查询的示例性替代示例；

图24图示了<facts>资源的示例性结构；

图25图示了<factRepository>资源的示例性结构；

图26图示了<reasoningRules>资源的示例性结构；

图27图示了<ruleRepository>资源的示例性结构；

图28图示了<semanticReasoner>资源的示例性结构；

图29图示了<reasoningRules>资源的示例性结构；

图30图示了<reasoningResult>资源的示例性结构；

图31图示了图13中公开的由RI触发的一次性推理的示例性OneM2M示例；

图32图示了图14中的由RI触发的连续推理的示例性OneM2M示例；

图33A图示了图15中的由推理支持的扩充IDB的示例性OneM2M示例；

图33B图示了图15中的由推理支持的扩充IDB的示例性OneM2M示例；

图34图示了示例性用户界面；

图35图示了语义推理功能(SRF)的示例性特征；

图36图示了语义推理功能的示例性特征；

图37A图示了其中可以实现所公开的主题的示例性机器到机器(M2M)或物联网(IoT)通信系统；

图37B图示了可以在图37A所示的M2M/IoT通信系统内使用的示例性体系架构；

图37C图示了可以在图37A所示的通信系统内使用的示例性M2M/IoT终端或网关设备；以及

图37D图示了其中图37A的通信系统的各方面的示例性计算系统。

具体实施方式

考虑如图5中所示的智能城市场景中的智能设施管理用例。多年来，大型医院已建造了许多建筑物。为了强制实施监控和设施管理目的，医院还在那些建筑物的房间中安装了监视相机。特别地，医院采用了基于SL的平台(例如，oneM2M)。例如，每个建筑物(例如，建筑物1、建筑物2和建筑物3)托管MN-CSE(例如，MN-CSE 105、MN-CSE 106和MN-CSE 107)，并且部署在建筑物房间中的每个相机向建筑物的对应MN-CSE注册并具有SL资源表示。例如，部署在建筑物-1的房间-109中的相机-111将在建筑物-1的MN-CSE 105上具有<Camera-111>资源表示，例如，可以是<AE>类型的资源，如oneM2M中所定义的。为了支持语义，可以用一些元数据作为语义注释来注释<Camera-111>资源。例如，一些事实可以被用于描述其设备类型和其位置信息，其以以下两个RDF三元组为例来编写：

·事实-1：相机-111是相机(“相机”是由本体定义的概念/类)

·事实-2：相机-111位于建筑物-1的房间-109中

对于域中的每个概念，其与其域本体中的类对应。例如，在大学上下文中，教师是概念，那么将“教师”定义为大学本体中的类。每个相机可以具有语义注释，其存储在语义子资源(例如，oneM2M<semanticDescriptor>资源)中。因此，数据的语义类型可以分布在MN-CSE的资源树中，因为不同的oneM2M资源可以具有其自己的语义注释。

医院将其设施集成到城市基础设施中(例如，作为实现智能城市的创新)，使得外部用户(例如，消防部门、城市卫生部门等)也可以管理、查询、操作和监视医院的设施或设备。

在每个医院建筑物中，房间被用于不同目的。例如，一些房间(例如，房间-109)将存储血液测试样本，而另一些房间将存储医用氧气瓶。由于房间的不同用途，医院已定义了几个“管理区(MZ)”并且每个区包括多个房间。注意的是，MZ的划分不一定基于地理位置，而是尤其可以基于使用目的。例如，MZ-1包括存储血液测试样本的房间。因而，城市卫生部门将对这些房间更加感兴趣。换句话说，城市卫生部门可以请求访问部署在属于MZ-1的房间中的相机。类似地，MZ-2包括存储医用氧气瓶的房间。因而，城市消防部门会对这些房间感兴趣。因而，城市消防部门可以访问部署在属于MZ-2的房间中的相机。每个MZ中的房间可以由于房间被医院设施团队重新布置或重新分配而随时间改变。例如，房间-109在其开始用于存储医用氧气瓶(例如，不再存储血液测试样本)时可以属于MZ-2。

考虑一种场景，其中潜在用户想要从属于MZ-1的房间中检索实时图像。为此，用户首先使用以下SPARQL语句-1进行语义资源发现以识别那些相机：

考虑到上述情况，本公开解决了潜在的问题。按照惯例，在资源发现过程期间，<Camera-111>资源将不被识别为期望资源，但是应当将其包括在发现结果中。原因是事实“设备-1位于建筑物-1的房间-109中”(这是<Camera-111>的语义注释)不能与SPARQL语句-1“？device monitors-room-in MZ-1”中的模式匹配，但是相机-111实际上部署在属于MZ-1的房间中。问题来自以下事实：设备的常规语义注释常常包括诸如物理位置之类的低级元数据，并且不包括关于MZ的高级元数据。但是，用户可能只对特定MZ(例如，MZ-1)下的房间感兴趣，而对那些房间的物理位置不感兴趣。参考上面的示例，用户仅对来自部署在属于MZ-1的房间中的相机的图像感兴趣，并且用户不必对物理房间或建筑物编号感兴趣。事实上，用户甚至可以不知道房间分配信息(例如，哪个房间用于哪个目的，因为这可以仅仅是由医院设施团队管理的内部信息)。话虽如此，推理或推断机制可以被用于解决这些问题。例如，了解以下推理规则：

·规则-1：IF A位于B中&&B在C的管理之下，THEN A监视C中的房间

通过使用事实-1、事实-2和规则-1，我们可以推断出新事实：

·相机-111监视MZ-1中的房间

这种新事实对于回答上面的SPARQL语句-1中示出的查询可能是有用的。

注意的是，高级查询可能无法直接匹配低级元数据，这种现象非常普遍，由于在许多计算机科学领域中在来自上层用户的查询基于高级概念(例如，术语或度量)而低层物理资源用低级元数据注释的意义上使用了“抽象”。作为示例，当用户查询膝上型计算机上的C：盘中的文件时，操作系统应当在硬盘驱动器上定位这个文件的物理块，这对用户是完全透明的。

虽然有一些现有的语义推理工具可用，但是由于从事实角度和推理规则角度的新问题，它们不能直接在基于SL的平台的上下文中使用。从事实的角度来看，数据或事实常常被分散或分布在不同地点(例如，现有的oneM2M<semanticDescriptor>资源中的RDF三元组)。因此，本文公开了一种高效方式来组织或集成相关的“事实筒仓”，以使输入(例如，事实集)准备好进行推理处理。从推理规则的角度来看，基于服务层(SL)的平台常常被假定为是启用跨不同部分的应用的水平平台。因此，可以基于应用需求或请求定义不同的定制或用户定义的规则，这会导致不同的推断事实(即使它们基于相同的初始事实)。

以下是问题的进一步描述。第一个问题是，从事实的观点来看，在许多情况下，初始输入事实可能不充分并且在可以执行推理操作之前还可以进一步识别附加事实作为输入。事实上，在服务层的上下文中，这个问题变得恶化，因为事实可以“分布”在不同地点并且难以收集。第二个问题是，从推理规则的角度来看，按照惯例，没有让SL实体定义、发布(例如，可以发布规则或事实，以便让其他人共享)用户定义的推理规则的方法以支持针对各种应用的推理。

第三个问题是，按照惯例，没有让SL实体通过将事实和规则指定为输入来触发“个体”推理处理的方法。但是，由于许多应用可能要求语义推理来识别隐含事实，因此可以要求或请求进行推理。例如，语义推理处理可以将公园的当前户外温度、湿度或风以及与户外活动顾问相关的推理规则作为两个输入。在执行推理处理之后，可以得出关于现在是否是进行户外运动的好时机的“高级推断事实”。在用户不必知道低级输入事实(例如，温度、湿度或风数)的细节的意义上，这种高级推断事实可以直接使用户受益。在另一个使用场景中，推断事实也可以用于扩充原始事实。例如，相机-111的语义注释最初包括一个三元组(例如，事实)，比如说相机-111是A：digitalCamera，其中A：digitalCamera是由本体A定义的类或概念。通过推理处理，推断事实可以被进一步添加到相机-111的语义注释中，诸如相机-111是B：highResolutionCamera，其中B：highResolutionCamera是由另一个本体B定义的类/概念。利用这种扩充，相机-111的语义注释现在具有更丰富的信息。

第四个问题是，按照惯例，对于充分利用语义推理作为“背景支持”来优化其它语义操作(诸如语义查询、语义资源发现等)的支持有限。在这种情况下，用户可能只知道他们正在发起特定的语义操作(诸如语义查询或语义资源发现等)。但是，在这个操作的处理期间，语义推理可以在后台被触发，这对用户是透明的。例如，用户现在可以在公园中发起针对户外运动推荐的语义查询。如果处理引擎仅具有原始事实(诸如公园的当前户外温度、湿度或风数据)，那么可能无法回答查询，因为SPARQL查询处理基于模式匹配(例如，匹配通常必须确切)。相比之下，如果可以使用那些原始事实通过推理来推断高级事实(例如，现在是否是进行运动的好时机)，那么这个推断事实可以直接回答用户的查询。

现有服务层不具有启用语义推理的能力，没有这种能力就不能有效地操作各种基于语义的操作。为了高效且有效地支持语义推理，应当实现本文公开的语义推理相关联的方法和系统中的一种或多种。总而言之，参考图6，方法和系统可以涉及以下三个部分：1)方框115-启用语义推理数据(例如，参考事实和规则)的管理；2)方框120-启用个体语义推理处理；以及3)方框125-利用背景推理支持来优化其它语义操作。方框115(部分1)关注于如何启用语义推理数据，以便事实集和规则集在服务层处可用。当事实集(FS)和规则集(RS)被启用并且语义推理器(SR)被启用时，可以在方框120(部分2)处发起个体语义推理处理，其中可以再次使用推断的结果。用于在未来的推理操作中输入。最后，在方框125(部分3)处，可以使用所公开的语义推理来更高效和有效地执行语义操作(例如，语义查询、语义资源发现、语义混搭(mashup)等)。本文更详细地公开了上面提到的方法和系统中的每一个。

应该理解的是，执行本文所示的步骤(诸如图7-图15)的实体可以是逻辑实体。所述步骤可以存储在设备、服务器或计算机系统(诸如图37C或图37D中所示的那些)的存储器中，并且可以在其处理器上执行。在示例中，利用下面关于M2M设备的交互的更多细节，图33A的AE 331可以驻留在图37A的M2M终端设备18上，而图33A的CSE 332和CSE 333可以驻留在图37A的M2M网关设备14上。在本文公开的示例性方法之间(例如，图7-图15)可以设想跳过步骤、组合步骤或添加步骤。

以下公开的是如何在SL中发布、更新和共享事实和推理规则(方框115–部分1)。已经定义了以下数据实体：事实集(FS)和规则集(RS)。事实集(FS)是事实的集合。当FS涉及语义推理时，可以通过InputFS或InferredFS对FS进行进一步分类。特别地，InputFS(方框116)是用作特定推理操作的输入的FS，而InferredFS(方框122)是语义推理结果(例如，InferredFS包括推断事实)。由推理操作A生成的InferredFS(方框122)可以被用作以后/未来的推理操作的InputFS(如图6中所示)。可以通过Initial_InputFS和Addi_InputFS进一步对InputFS进行分类(例如，参见图13)。当推理发起者(RI)向语义推理器(SR)发送用于触发语义推理操作的请求时，RI可以提供Initial_InputFS。如果在语义推理操作中应当使用附加事实，那么由SR进一步提供或决定Addi_InputFS。在以下描述中，通用术语FS可以被用于覆盖多种类型的事实集。规则集(RS-例如，RS 117)是推理规则的集合。RS可以通过Initial_RS和Addi_RS进一步分类。例如，当RI向SR发送用于触发语义推理操作的请求时，由RI提供Initial_RS。如果在语义推理操作中应当使用附加规则，那么由SR进一步提供或决定Addi_RS。Initial_InputFS是指由推理发起者(RI)提供的FS。例如，当RI向SR发送推理请求时，RI可以指示什么事实将作为推理输入，这些事实将被视为Initial_InputFS。然后，SR可以发现Initial_InputFS是不够的，它可以包括更多事实作为输入，这将被视为Addi_InputFS。

从FS的角度来看，在服务层中，数据通常作为资源暴露，并且事实分散或分布在不同的地点。事实不限于普通SL资源的语义注释(例如，不同<semanticDescriptor>资源中的RDF三元组)，事实还可以指可以使之在服务层处可用(例如，发布)并存储或被其他人访问的任何信息或知识。例如，FS的特殊情况可以是可以存储在oneM2M中定义的<ontology>资源中的本体。

从RS的角度来看，基于SL的平台常常被假定为是支持跨不同域的应用的水平平台。因此，可以使不同的RS在服务层处可用(例如，发布)并存储或被其他人访问以支持不同的应用。例如，对于描述公园中当前户外温度、湿度或风的InputFS，可以使用与户外活动顾问相关的推理规则来推断现在是否是进行户外运动的好时机的高级事实(可以被直接消化)。相比之下，智能草坪浇水相关规则可以被用于推断当前浇水时间表是否是期望的事实。总体而言，根据如何使FS或RS在服务层处可用及其相关的CRUD(创建、读取、更新和删除)操作，方框115-部分1与如何启用语义推理数据相关联。

这部分介绍用于FS启用的CRUD操作，使得可以发布、访问、更新或删除给定的FS(同时覆盖InputFS和InferredFS情况)。

在以下过程中，涉及一些“逻辑实体”并且每个逻辑实体具有对应的角色。它们被如下列出：

·事实提供者(FP)：这是创建给定FS并使其在SL处可用的实体(例如，oneM2M AE或CSE)。

·事实主机(FH)：这是可以托管给定FS的实体(例如，oneM2M CSE)。

·事实修改者(FM)：这是在现有FS上进行修改或更新的实体(例如，oneM2M AE或CSE)。

·事实消费者(FC)：这是检索在SL处可用的给定FS的实体(例如，oneM2M AE或CSE)。

因而，不同的物理实体可以担任如上定义的不同逻辑角色。例如，AE可以是FP并且CSE可以是FH。一个物理实体(诸如oneM2M CSE)可以担任如上定义的多个角色。例如，CSE既可以是FP，也可以是FH。AE可以是FP，以后也可以是FM。

图7图示了用于FS发布的CREATE操作的示例性方法。如图7中所示，可以有发布FS-1所涉及的FP 131和FH 132。步骤140可以是发布方法的前提条件。在步骤140处，FP 131具有事实集，其被表示为FS-1。FP 131打算(例如，基于触发来确定)以使FS-1在系统中可用。例如，可能的触发器是：如果可以使FS-1对外部实体可用，那么这可以触发FP 131向服务层发布FS-1。在步骤141处，FP 131将FS-1发送到FH 132以进行发布。注意的是，FS一般可以具有几种形式。例如，FS-1可以是指本体，其描述给定用例的域知识(例如，如本文所公开的智能城市用例，其中定义了许多域概念及其关系，诸如医院、城市消防部门、建筑物、房间等)。另一个示例，FS-1可以指与特定实例相关的事实。仍然使用图5的先前示例，FS可以描述医院的当前管理区定义，诸如医院的建筑物、房间布置、分配信息(例如，管理区MZ-1包括用于存储血液测试样本的房间，诸如建筑物-1中的房间-109、建筑物-3中的房间-117等)。对于这些类型的事实，它可以单独存在于系统中(例如，不一定要作为其它资源的语义注释)。此外，FS还可以指关于系统中的资源、实体或其它事物的语义注释。继续参考图5，FS可以是相机-111的语义注释，其部署在建筑物-1的房间-109中。

在步骤142处，继续参考图7，FH 132决定是否可以在其上存储FS-1。例如，FH 132可以检查FP 131是否具有这么做的适当访问权限。如果FS-1可以存储在其上，那么FH 132将存储FS-1，可以使FS-1对系统中的其它实体可用。例如，以后的语义推理处理可以使用FS-1作为输入，并且在那种情况下，将检索FS-1并将其输入到SR中进行处理。关于给定的FS，某些信息也可以被存储或与该FS相关联，以便指示一些有用的信息(该信息可以由FP131在步骤141中或由其他人提供)。例如，该信息可以包括相关的本体或相关的规则。

关于相关本体，存储在FS-1中的事实可以使用由某些本体定义的概念或术语，因此，指出哪些本体涉及那些事实是有用的(使得可以准确解释那些RDF三元组中的主语/谓语/宾语的含义)。例如，考虑存储在FS-1中的以下事实：

·事实-1：相机-111位于建筑物-1的房间-109中

·事实-2：建筑物-1的房间-109由MZ-1管理

可以观察到，FS-1中的事实使用一些术语，诸如“位于…中”或“由…管理”，这可以是由特定本体定义的词汇或特性。

参考相关规则，也有可能将存储在FS-1中的事实潜在地用于根据某些推理规则进行推理，因此，指出哪些潜在的RS可以应用于这个FS-1进行推理也是有用的。注意的是，那些规则仅仅是建议，从某种意义上说，只要合理，也可以对该FS-1应用其它规则。考虑存储在RS-1中的以下推理规则：

·规则-1：IF A位于B中&&B在C的管理之下，THEN A监视C中的房间

RS-1(规则-1)中的规则可以应用于存储在FS-1(事实-1和事实-2)中的事实。在步骤143处，FH 132确认FS-1现在存储在FH132上。

图8图示了用于FS检索的RETRIEVE操作的示例性方法。如图8中所示，可以存在FC133，该FC 133可以检索存储在FH 132上的FS-1。在步骤150处，检索方法可以存在前提条件。在步骤150处，FC 133已经在FH 132上进行了资源发现操作并且识别出了感兴趣的FS(例如，FS-1)。仍然使用图5的先前示例，如果FS-1描述了医院的当前管理区定义，诸如它的房间分配信息，那么SR可以在推理处理期间使用它。例如，FS-1可以对于识别感兴趣的相机 是有用的，所述相机仅用物理位置信息(例如，房间和建筑物编号)而未用与管理区相关的 信息进行注释。当用户在寻找部署在属于MZ-1的房间中的相机时，这种FS-1对于通过推理处理识别相关相机将是有用的。在步骤151处，FC 133向FH 132发送检索FS-1的请求。在步骤152处，FH 132决定是否允许FC 133检索FS-1。如果是这样，那么FH 132将把FS-1的内容返回给FC 133。在步骤153处，将FS-1的内容返回给FC 133。

关于UPDATE或DELETE操作，FM 134可以使用如图9所示的以下过程来更新或删除存储在FH 132上的FS-1。在步骤160处，先前已将事实集(FS-1)发布到FH 132或由FH 132本地生成。现在，FM 134打算(例如，基于触发器来确定)更新FS-1中的内容或打算删除FS-1。例如，FM已接收到FS-1已过期的通知，然后触发更新或删除。仍然使用图5的先前示例，假设FS-1描述医院的管理区定义，诸如其房间分配信息，那么如果医院已重新组织房间分配，那么可以要求或请求FS-1更新(例如，现在建筑物-1的房间109不再属于MZ-1，因为它不是用于存储血液样本，而是用于其它目的)。在步骤161处，FM 134向FH 132发送更新请求以修改存储在FS-1中的内容，或者发送删除请求以删除FS-1。在步骤162处，FH 132决定是否可以允许这个更新或删除请求(例如，基于某些访问权限)。如果允许，那么将基于从FM 134发送的请求来更新或删除FS-1。在步骤163处，FH 132确认FS-1已经被更新或删除。作为替代方法，如果存储在FS中的事实采用RDF三元组的形式，那么可以使用SPARQL查询语句来更新FS。为了这样做，在步骤161中，更新请求可以包括描述应当如何更新FS的SPARQL查询语句。特别地，在这种方法中，FS可以被完全更新或部分更新，这取决于SPARQL查询语句如何被编写。替代方法的示例可以包括当FM是完全具有语义能力的用户并且知道SPARQL查询语言时，FM可以以SPARQL查询语句的形式直接编写其更新要求或请求。

这部分介绍用于RS启用的CRUD操作，以便可以发布、访问、更新和删除给定的RS。RS启用一般是指定制或用户定义的规则。在以下过程中，涉及一些“逻辑实体”，并且每个逻辑实体都具有对应的角色。它们被列出如下：

·规则提供者(RP)：这是创建给定的RS并使其在SL处可用的实体(例如，oneM2MAE或CSE)。

·规则主机(RH)：这是可以托管给定RS的实体(例如，oneM2M CSE)。

·规则修改者(RM)：这是在现有RS上进行修改(例如，更新)的实体(例如，oneM2MAE或CSE)。

·规则消费者(RC)：这是检索在SL处可用的给定RS的实体(例如，oneM2M AE或CSE)。

因而，不同的物理实体可以担任如上定义的不同逻辑角色。例如，AE可以是RP，并且CSE可以是RH。一个物理实体(诸如oneM2M CSE)可以担任如上定义的多个角色。例如，CSE既可以是RP，也可以是RH。AE可以是RP，后来也可以是RM。

关于CREATE操作，RP 135可以使用以下过程来发布RS-1并将其存储在RH 136上，如图10中所示。作为前提条件，在步骤170处，RP 135具有规则集，其被表示为RS-1。RP 135打算使RS-1在系统中可用。可能的触发器是如果可以使RS-1对外部实体可用，那么这可以触发RP 135将FS-1发布到服务层。在步骤171处，RP 135将RS-1发送到RH 136以进行发布。仍然使用图5的先前示例，RS-1可以包括以下规则：“IF A(例如，相机-111)位于B中(例如，建筑物-1的房间-109)，并且B在C(例如，MZ-1)的管理之下，THEN A监视C中的房间”。这种规则对于推断新事实可以是有用的，该新事实可以将相机与特定的MZ相关联。在步骤172处，RH 136基于某个访问权限来决定是否可以在其上存储RS-1。如果可以在其上存储RS-1，那么RH 136可以存储RS-1，该RS-1对于系统中的其它实体可用。例如，以后的语义推理处理可以使用RS-1作为输入，并且在那种情况下，可以检索RS-1并将其输入到SR中进行处理。某些信息也可以被存储或与该RS相关联以指示一些有用的信息。这个信息可以由RP 135在步骤171中或由其他人提供。例如，该信息可以包括相关的本体或相关的事实。关于相关的本体，存储在RS中的规则有可能使用由某些本体定义的概念或术语，因此，指示那些规则中涉及哪些本体是有用的。例如，考虑存储在RS-1中的以下用户定义的推理规则：

·规则-1：IF A位于B中&&B由C管理，THEN A监视C中的房间

规则1使用一些术语，诸如“位于…中”或“由...管理”，它们可以是由特定本体定义的词汇/特性。

关于相关的事实，也有可能将存储在RS中的规则应用于某些类型的事实，因此，指示该RS可以应用于哪些潜在FS来进行推理也是有用的。注意的是，如果在FS中使用的术语与在RS中使用的术语有重叠，那么在某种意义上，那些事实仅仅是建议，该RS也可以应用于其它事实。例如，考虑以下两个事实存储在FS-1中，它们被描述为RDF三元组：

·事实-1：相机111位于建筑物-1的房间-109中

·事实-2：建筑物-1的房间-109由MZ-1管理。

RS-1(规则1)中的规则可以应用于存储在FS-1中的事实(事实-1和事实-2)，因为事实中使用的本体与规则中使用的本体之间存在重叠，诸如像“位于…中”或“由...管理”之类的那些术语。在步骤173处，RH 136确认RS-1现在利用URI存储在RH 136上。

这个部分中示出可以如何创建推理规则。首先，基于各种应用场景或要求，可以定义各种应用驱动的推理规则，诸如在前面讨论的智能设施管理用例中定义的那些规则：

·规则-1：IF A位于B中&&B配备有备用电源，THEN A配备有备用电源

第二，可以生成推理规则的另一种情况是在进行本体对齐或映射时。本体对齐或本体匹配是确定本体中概念之间的对应关系的过程。作为示例，对于给定的本体A和本体B，可以不进行本体映射，并且识别出的映射之一可以是本体A中的概念或类“记录”等于或相同于本体B中的概念/类“日志记录”。概念通常与本体中定义的类对应。因此，通常，概念和类是指相同的事情。在此，在本体A中定义称为“记录”的类并且在本体B中定义称为“日志记录”的类。因而，该映射可以被描述为RDF三元组(使用OWL中定义的“sameAs”谓语)，诸如以下三元组：

·RDF三元组-A：ontologyA:Record owl:sameAsontologyB:LogRecord

关于如何进一步利用该RDF三元组-A有多种方法，诸如下面提供的。换句话说，RDF-A三元组已经是两个本体之间的映射结果。现在在下面讨论还可以利用这个映射结果的示例性方式。在第一种方式中，可以将RDF三元组-A添加到记录(例如，记录-X)的语义注释。例如，对于给定的记录-X，最初它的语义注释仅仅包括以下RDF三元组(这表明记录-X是本体B中LogRecord概念/类的实例)：

·RDF三元组-B：记录-X是ontologyB:LogRecord

因而，如果用户希望用以下SPARQL查询语句进行语义发现：

·SELECT？rec WHERE{？rec is-a ontologyA:Record}

用户无法在发现结果中得到记录-X，因为上述SPARQL查询语句无法与记录-X的语义注释匹配(因为记录-X是ontologyB:LogRecord类型，而用户在寻找ontologyA:Record类型的记录)。为了解决这个问题，我们可以将RDF三元组-A添加到记录-X的语义注释中。然后，当在语义发现操作期间处理上述SPARQL语句时，可以通过对记录-X的语义注释应用某些推理规则来触发推理，例如：

·规则-2：IF uuu owl:sameAs vvv并且Y是uuu，THEN Y是vvv(在此，“uuu”、“vvv”、“Y”都是要替换的通配符。)

因此，推理结果为以下三元组：

·RDF三元组-C：记录-X是ontologyA:Record

然后，这种RDF三元组-C可以匹配原始SPARQL语句(例如，模式WHERE{？rec is-aontologyA:Record})，并最终在该语义发现操作期间识别出记录-X。

第二种方式将RDF三元组-A转换成推理规则以供进一步使用。例如，RDF三元组-A可以表示为以下推理规则：

·规则-3：IF Y是ontologyB:LogRecord，THEN Y是ontologyA:Record。

然后，可以通过使用本公开中定义的RS启用过程将这种推理规则存储在服务层中(例如，使用CREATE操作在主机上创建RS)。在oneM2M中，这可以意味着我们可以使用CREATE操作来创建<reasoningRule>资源以存储规则-3)。

仍然使用先前的示例(如前面所讨论的记录-X和SPARQL语句)。在这种方法中，我们不将RDF三元组-A添加到记录-X的语义注释中。代替地，当在语义发现操作期间处理上述SPARQL语句时，可以通过使用规则-3触发语义推理。因此，推理结果可以与RDF三元组-C相同。最终，在该语义发现操作期间还可以识别记录-X。

关于RETRIEVE操作，RC 137可以使用以下过程来检索存储在RH 136上的RS-1，如图11中所示。作为前提条件，在步骤180处，RC 137已在RH 136上进行了资源发现操作并识别出感兴趣的RS-1。例如，RC 137是SR，并且打算使用RS-1进行推理操作(例如，在这种情况下，SR担任RC的逻辑角色)。在步骤181处，RC 137向RH 136发送用于检索RS-1的请求。在步骤182处，RH 136决定是否允许RC 137检索RS-1。如果是，那么RH 136将把RS-1的内容返回给RC 137。在步骤183处，RS-1的内容返回给FC 133。

关于UPDATE/DELETE操作，RM 138可以使用以下过程来更新或删除存储在RH 136上的RS-1，如图12中所示。作为前提条件，在步骤190处，先前已将规则集(RS-1)发布到RH136。现在，RM 138打算(例如，基于触发器来确定)更新RS-1中的内容或打算删除RS-1。例如，触发器可以是RM 138已接收到RS-1过期的通知，于是需要更新或删除它。仍然使用先前图5的示例，RS-1最初仅包括一个推理规则。但是，可以添加新的推理规则来推断关于设备访问权限的更多事实。例如，新规则可以是“IF A(例如，相机-111)在B(例如，用于存储血液测试样本的房间的MZ-1)的管理之下，并且B对C暴露(例如，城市卫生部门知道MZ-1)，THEN允许C访问A(例如，城市卫生部门可以访问相机-111)。使用这个新规则进行推理，可以将推断出的事实用于回答查询，诸如城市卫生部门可以访问哪些设备。在步骤191处，RM 138向RH 136发送更新请求以修改存储在RS-1中的内容或者发送删除请求以删除RS-1。在步骤192处，RH 136基于某个访问权限来决定是否允许该更新/删除请求。如果是，那么RS-1将基于从RM 138发送的请求被更新/删除。在步骤193处，RH 136确认RS-1已经被更新/删除。

这部分介绍用于启用个体语义推理处理的几种方法和系统。第一示例方法可以与一次性推理操作相关联。对于这个操作，推理发起者(RI)已识别出一些感兴趣的InputFS和RS，并希望在SR处发起推理操作以识别一些新事实(例如，知识)。第二示例方法可以与连续推理操作相关联。在这个系统中，可以要求或请求RI在相关的InputFS和RS上发起连续推理操作。原因是InputFS和RS有可能随时间改变(例如，更新)，因而先前的推断事实可能不再有效。因而，应当在最新的InputFS和RS上执行新的推理操作，并产生更多新鲜的推断事实。

使用先前的示例，语义推理处理可以将公园的当前户外温度/湿度/风(作为InputFS)和与户外活动顾问相关的推理规则(作为RS)作为两个输入。在执行推理处理后，可以推断出关于例如现在是否是进行户外运动的好时机的高级事实(作为InferredFS)。在此，“个体”一词意味着语义推理处理不必与其它语义操作(例如，语义资源发现、语义查询等)相关联。为了启用语义推理处理，它涉及许多问题，诸如：

1.要使用的InputFS是什么以及去哪收集它？

2.要使用的RS是什么以及去哪收集它？

3.谁将负责收集InputFS和RS？例如，它可以是发起语义过程的应用实体，或者SR可以处理这个过程。

4.一旦InferredFS由RS产生，它将在哪里递送或存储？

以下公开的方法和系统解决了上面提到的问题。仍涉及一些先前定义的“逻辑实体”，诸如FH和RH。此外，SR在系统中可用，并且称为推理发起者(RI)的新逻辑实体是可以向SR发送请求以触发推理操作的逻辑实体。

在关于一次性推理的这种场景中，RI已经识别出一些感兴趣的InputFS和RS，并且愿意发起在SR处的推理操作以便发现一些新的知识/事实。本文公开了提供在服务层处触发一次性推理操作的方式的系统、方法或装置。图13图示了用于一次性推理操作的示例性方法，并且详细描述如下。在步骤200处，前提条件是RI 231知道SR 232的存在。RI 231可以是AE或CSE。通过发现，RI 231在FH 132上识别出感兴趣的事实的集合(这个事实集被表示为Initial_InputFS)并且在RH 136上识别出一些推理规则(这个规则集被表示为Initial_RS)。RI 231也可能首先识别Initial_InputFS部分，并且如果还有关于Initial_InputFS的更多信息可用(例如，如果“相关规则”信息也可用(这指示可以在Initial_InputFS上应用哪些潜在的RS以用于推理)，那么RI 231可以直接从那些建议中选择一些感兴趣的规则。关于贯穿本公开讨论的已识别出的“感兴趣的”事实和规则，推理发起者(RI)可以使用现有的语义资源发现来识别存储事实或推理规则的oneM2M资源。一般而言，在语义发现请求中，语义过滤器和这个过滤器可以携带SPARQL语句。这个SPARQL语句可以指示RI感兴趣的事实或规则的类型(即，请求消息包括对关于某些数据的更多信息的请求)。例如，RI可以说“请为我找到关于市区路灯的所有事实，例如，其生产年份、品牌、位置等。”---这是RI感兴趣的事实。RI也可以说“请为我找到表示路灯维护计划的推理规则。例如，规则可以写为：IF路灯是X品牌，或者它位于特定道路，THEN需要立即对这个灯进行升级”---这是RI感兴趣的规则。然后，如果RI(例如，城市路灯维护应用)想要知道应当升级哪些灯(这可以是当RI“打算…”的示例)，那么这个RI可以使用识别出的事实和规则来触发如图13中所示的推理操作，并且推理结果是需要升级的路灯列表。因此，简而言之，RI感兴趣的事实或规则的类型可以取决于应用业务需求。

作为示例，RI 231对两个相机(例如，相机-111、相机-112)感兴趣并且Initial_InputFS具有关于那两个相机的若干事实，诸如以下：

·事实-1：相机-111具有品牌名称“XYZ”

·事实-2：相机-112位于建筑物-1中

RI 231还识别以下规则(作为Initial_RS)并且打算将其用于推理，以便发现关于那些感兴趣的相机的更多隐含知识/事实：

·规则-1：IF A具有品牌名称“XYZ”，THEN A配备有备用电源

利用那些Initial_InputFS和Initial_RS，有可能推断出关于那些相机是否具有备用电源的一些新知识，使得即使发生断电它们也可以支持7*24监视目的。在步骤201处，RI 231打算(例如，基于触发来确定)使用Initial_InputFS和Initial_RS作为输入来触发SR 232处的推理操作/作业以发现一些新知识。RI 231发出推理请求的触发可以是RI 231在先前的发现操作期间接收到“非空”的事实和规则集，然后这可以触发RI发出推理请求。换句话说，如果Initial_RS和Initial_FS非空，那么它可以触发RI 231发送推理请求。在步骤202处，RI 231向SR 232发送推理请求，以及关于Initial_InputFS和Initial_RS的信息(例如，它们的URI)。例如，该信息包括用于存储Initial_InputFS的对应FH 132的URI、用于存储Initial_RS的对应RH 136的URI。在步骤203处，基于从RI 231发送的信息，SR 232从FH132检索Initial_InputFS-1并从RH 136检索Initial_RS。

在步骤204处，除了由RI 231提供的输入之外，SR 232还可以确定在这个语义推理操作中是否可以使用附加FS或RS。如果SR 232知道可替代的FH和RH，那么可以查询它们以获得附加FS或RS。

例如，RI 231有可能仅识别出部分事实和规则(例如，RI 231没有在FH 234和RS-2上进行发现，但是在FH 234和RS-2上也有RI 231感兴趣的有用的FS和RS)，这会限制SR推断新知识的能力。例如，仅利用Initial_InputFS和Initial_RS，SR 232可以产生一条新事实：

·推断事实-1：相机-111配备有备用电源

一般而言，在这个步骤204中，是否SR 232将使用附加事实或附加规则可以具有不同的实现选择。例如，在第一种方法中，RI 231可以在步骤202中指示SR 232是否可以添加附加事实或规则。在第二种方法中，RI 231在步骤202中可以不指示SR 232是否可以添加附加事实或规则。代替地，SR 232的本地策略可以做出这种决定。

继续参考步骤204，一般而言，有以下可能的方式用于SR 232决定可以利用哪些附加FS和RS。这可以通过在SR 232上设置一些本地策略或配置来实现。例如：

·对于Initial_InputFS中包括的给定FS(例如，FS-1)，SR 232还可以检查是否有与FS-1相关联的(例如，存储的)有用信息。例如，信息可以包括“相关规则”，该“相关规则”指示可以在FS-1上应用哪些潜在RS以进行推理。如果那些相关规则的任何部分没有被包括在Initial_RS中，那么RI 231还可以决定是否添加那些相关规则中的一些作为附加规则。

·对于Initial_RS中包括的给定RS(例如，RS-1)，SR 232还可以检查是否存在与RS-1相关联/存储的有用信息。例如，信息之一可以是“相关事实”，该事实指示RS-1可以应用于哪些可能的FS。如果这些相关事实的任何部分都未包括在Initial_InputFS中，那么RI231还可以决定是否添加那些事实中的一些作为附加事实。

·如上面所讨论的，当SR 232无法从Initial_InputFS和Initial_RS得到有用信息时，SR 232也可以基于其本地配置或策略采取动作。例如，SR 232可以被配置为使得只要它看到Initial_InputFS或Initial_RS中使用的某些本体或感兴趣的术语/概念/谓语，它就还可以检索更多的事实或规则。换句话说，SR 232可以保持本地配置表以记录其感兴趣的关键词，并且每个关键词可以与多个相关的FS和RS相关联。因而，对于在Initial_InputFS和Initial_RS中出现的任何关键词(术语、概念或谓语)，SR 232可以检查其配置表以找出该关键词的相关联的FS和RS。如果尚未将那些相关联的FS和RS包括在Initial_InputFS和Initial_RS中，那么那些相关联的FS和RS可以潜在地是可以被利用的附加FS和RS。例如，当SR 232接收到事实-2并且它发现事实-2中出现了术语“建筑物-1”时(例如，“建筑物-1”是其配置表中的感兴趣术语或关键词)，那么SR 232可以选择添加关于建筑物-1的附加事实(例如，基于其配置表中的信息)，诸如下面示出的事实-3。类似地，由于SR 232发现在事实-2中出现了感兴趣的谓语“位于…中”并且在事实-3中出现了感兴趣的谓语“配备有”，因此它将添加附加/更多规则，诸如如下所示的规则-2：

·事实-3：建筑物-1配备有备用电源

·规则-2：IF A位于B中&&B配备有备用电源，THEN A配备有备用电源

·还可以配置SR 232，使得在给定RI 231的类型的情况下，应当利用附加的FS和RS。(例如，取决于RI的类型；例如，如果RI是VIP用户，那么在推理处理中可以包括更多FS，从而可以产生高质量的推理结果。)

在步骤204处的方法也可以在后面的部分的方法(诸如图14中的步骤214和图15中的步骤225)中使用。

在步骤205处，SR 232从FH 234检索附加FS(表示为Addi_InputFS)并从RH 235检索附加RS(表示为Addi_RS)。例如，Addi_InputFS具有关于建筑物-1的如上所示的事实-3，并且Addi_RS具有如上所示的规则-2。利用附加的FS和RS以及事实-2，SR 232可以得出推断事实-2：

·推断事实-2：相机-112配备有备用电源

在步骤206处，利用所有InputFS(例如，Initial_InputFS和Addi_InputFS)和RS(例如，Initial_RS和Addi_RS)，SR 232将执行推理处理并产生InferredFS。如前面所提到的，两个推断事实(推断事实-1和推断事实-2)将包括在InferredFS中。在步骤207处，SR232将InferredFS发送回RI 231。

作为复习，概念等于本体中的类，诸如教师、学生、课程，这些都是大学本体中的概念。谓语描述类之间的“关系”，例如，教师“教”课程。术语常常是域中的关键词，每个人都理解，例如“全职”。考虑以下RDF三元组(就主语-谓语-宾语而言)：

RDF三元组1：Jack是教师(在此，“教师”是类，Jack是类“教师”的实例)。

RDF三元组2：Jack教课程-232(在此，这个RDF三元组中的“教”是谓语)。

RDF三元组3：Jack的工作状态为“全职”(在此，“全职”是众所周知的术语)

图13中所示的过程的几种替代方案也定义如下(替代方案可以分开考虑)。步骤201的替代方案-1，RI 231不必进行发现以识别Initial_InputFS和Initial_RS。代替地，RI231本身可以自己生成Initial_InputFS和Initial_RS并将它们发送到SR 232(在这种情况下，不要求步骤203)。

步骤201的替代方案-2，RI 231不必使用用户定义的推理规则集。代替地，它也可以利用现有的标准推理规则。例如，SR 232有可能支持基于由特定W3C蕴含机制(诸如RDFS蕴含、OWL蕴含等)定义的推理规则的全部或部分进行推理(例如，在这种情况下，Initial_RS可以指那些标准推理规则)。为了这样做，当RI 231首次发现SR 232时，RI 231可以询问SR 232它可以支持哪些标准推理规则或蕴含机制。

替代方案-3，步骤202的替代，RI 231可以仅发送关于Initial_InputFS和Initial_RS的位置信息。然后，SR 232可以代表RI 231检索Initial_InputFS和Initial_RS。

考虑到语义推理操作可能花费一些时间的事实，还可以支持替代方案-4，替代方案-4是用于触发语义操作的非基于块的方法。例如，在步骤203之前，SR 232可以首先发回关于对从RI 231发送的请求的接受的快速确认。并且在SR 232计算出推理结果(例如，InferredFS)之后，它将如步骤207中所示将InferredFS发送回RI 231。注意的是，在基于块的方法中，当RI向SR发送请求时，在SR计算出推理结果之前，SR不会将任何响应发送回RI。相比之下，在非块方法中，当SR接收到推理请求时，SR可以将快速确认发送回RI。然后，在稍后的时间里，当SR计算出推理结果时，它还可以将推理结果发送给RI。

替代方案-5，步骤207的另一个替代方案，是不必将InferredFS返回给RI 231。代替地，可以基于要求或计划使用将其存储在某些FH中。例如：

1.SR 232可以将InferredFS与Initial_InputFS集成在一起，使得Initial_InputFS将比以前更“扩充”。在Initial_InputFS是设备的语义注释的情况下，这是有用的。利用InferredFS，语义注释可以具有更丰富的信息。例如，在开始时，Initial_InputFS可以仅描述“相机-111是OntologyA:VideoCamera”的事实。在进行推理之后，生成推断事实(相机-111是OntologyB:DigitalCamera)，也可以将其添加为相机-111的语义注释。以这种方式，相机-111有更好的机会在以后的发现操作中被成功识别(即使没有推理支持)，这些操作或者使用本体A中定义的概念“VideoCamera”或者本体B中定义的概念“DigitalCamera”。

2.SR 232可以创建新资源以将InferredFS存储在FH 132上或本地存储在SR 232上，并且SR 232可以仅返回资源URI或InferredFS在FH 132上的位置。在Initial_InputFS描述设备的一些底层语义信息而InferredFS描述一些高级语义信息的情况下，这是有用的。例如，Initial_InputFS可以仅描述“相机-113位于房间147中”的事实，而InferredFS可以描述“相机-113监视患者-Mary”的事实。这种高级知识不应当与相机-113的低级语义注释集成。

对于替代方案-6，值得注意的是，在所公开的方法中，我们考虑从一个FH 132或一个RH 136检索特定规则集或事实集(例如，Initial_InputFS、Addi_InputFS、Initial_RS、Addi_RS)的情况，这只是为了更容易演示。一般而言，Initial_InputFS(以及类似地对于Addi_InputFS)可以由多个FH上托管的多个FS组成。Initial_RS(以及类似地对于Addi_RS)可以由多个RH上托管的多个RS组成。注意的是，所有上述替代方案也可以应用于本文公开的其它类似方法(例如，图14的方法)。

连续推理操作：在这种场景中，RI 231可以在相关的FS和RS上发起连续推理操作。原因是有时InputFS和RS会随时间改变/更新，因而先前的推断事实可能不再有效。因而，可以在最新的InputFS和RS上执行新的推理操作，并产生更新鲜的推断事实。图14图示了用于连续推理操作的示例性方法，并且详细描述如下。在步骤210处，作为前提条件，RI 231知道SR 232的存在。通过发现，RI 231已经在FH 132上识别出感兴趣的事实的集合(这个事实集被表示为Initial_InputFS)并在RH 136上识别出一些推理规则(这个规则集被表示为Initial_RS)。在步骤211处，RI 231打算(例如，基于触发器来确定)使用Initial_InputFS和Initial_RS来发起“连续”语义推理操作。在示例中，用于RI 231发出推理请求的触发可以是RI 231在先前的发现操作期间接收到“非空”的事实和规则集。同时，识别出的事实或规则可以随时间改变，然后这可以触发RI 231发送针对连续推理操作的请求。在步骤212处，RI 231将推理请求连同关于Initial_InputFS和Initial_RS的信息一起发送到SR 232。注意的是，请求消息可以包括新的参数reasoning type(rs_ty)。Reasoning type(rs_ty)指示RI 231要求哪种类型的推理操作。例如，rs_ty＝0意味着一次性推理操作(如前一部分中所讨论的)，而rs_ty＝1意味着连续推理操作。可替代地，当请求消息中不存在rs_ty时，它将被视为一次性推理请求。

在步骤213处，基于从RI 231发送的信息，SR 232从FH 132检索Initial_InputFS并从RH 136检索Initial_RS。SR 232还对其进行订阅，以通知任何改变。在步骤214处，除了由RI 231提供的输入之外，SR 232还可以决定在这个语义推理操作中是否可以使用附加的FS或RS。在步骤215处，SR 232从FH 234检索附加的FS(表示为Addi_InputFS)并从RH 235检索附加的RS(表示为Addi_RS)，并且还对其进行订阅。

在步骤216处，SR 232创建推理作业(表示为RJ-1)，其包括所有InputFS(例如，Initial_InputFS和Addi_InputFS)和RS(例如，Initial_RS和Addi_RS)。然后，将执行RJ-1并产生InferredFS。之后，只要Initial_InputFS、Addi_InputFS、Initial_RS和Addi_RS中的任何一个被改变，就会触发RJ-1再次执行。可替代地，SR 232也可以选择周期性地检查那些资源并查看是否存在更新。另一个替代方案，RI 231也可以主动地和仿冒地(parodically)发送请求以获取RJ-1的最新推理结果，并且在这种情况下，每次SR 232接收到RI 231的请求时，SR 232也可以选择检查那些资源并查看是否存在更新(如果存在的话，那么将触发新的推理)。

在步骤217处，FH 132发送关于对Initial_InputFS的改变的通知。在步骤218处，SR 232将检索Initial_InputFS的最新数据，然后对RJ-1执行新的推理处理并产生新的InferredFS。注意的是，在初始语义推理处理之后，步骤217-步骤218可以连续地操作，以应对对相关FS和RS(例如，在这个示例中示出的Initial_InputFS)的改变。每当SR 232接收到关于对Initial_InputFS的改变的通知时，它将检索Initial_InputFS的最新数据并执行新的推理处理以生成新的InferredFS。在步骤219处，SR 232将新的InferredFS连同RJ-1的作业ID一起发送回RI 231。只要RJ-1是在SR 232中运行的有效语义推理作业，与RJ-1相关的这整个语义推理处理就可以继续。此外，如果RJ-1到期或者SR 232或RI 231选择终止RJ-1，那么SR232将停止处理与RJ-1相关的推理，并且SR 232也可以从相关的FS和RS取消订阅。图13中所示的替代方案也可以应用于图14中所示的方法。

这部分介绍了有关其它语义操作(诸如语义查询、语义资源发现、语义混搭等)如何从语义推理中受益的方法和系统。除了语义推理器，语义引擎(SE)在系统中也可用，它是那些语义操作的处理引擎。一般过程是：语义用户(SU)可以通过向SE发送请求来发起语义操作，该请求可以包括SPARQL查询语句。特别地，SU没有意识到可以在SE后面提供帮助的SR。对于SE，它可以首先为对应的SPARQL查询语句决定涉及的数据基础(IDB)。一般而言，IDB指的是应当在其上执行SPARQL查询语句的事实集(例如，RDF三元组)。但是，手头的IDB可能并不完美，无法为请求提供期望的响应。因而，SE还可以联系SR以获得语义推理支持，以便促进在SE处的语义操作的处理。特别地，公开了扩充IDB。对于扩充IDB，利用推理能力，因此原始IDB将被扩充(由于推理的帮助，通过将一些新的推断事实集成到初始事实中)，但是原始查询语句将不会被修改。因而，SE将原始查询语句应用于“扩充的IDB”以便生成处理结果(例如，SE正在处理语义查询，处理结果将是语义查询结果。如果SE正在处理语义资源发现，那么处理结果将是语义发现结果)。

在部分3(方框125)中，语义推理的作用更像是“后台支持”，以提高其它语义操作的有效性，并且在这种情况下，推理对前端用户可以是透明的。换句话说，在部分3(方框125)中用户可以只知道他们正在发起特定的语义操作(诸如语义查询或语义资源发现、语义混搭等)。但是，在由SE 233处理这个操作期间，SE 233还可以求助于SR 232的支持(在这项工作中，术语SE用作处理除语义推理之外的语义操作的引擎。换句话说，推理处理将由SR专门处理)。考虑到先前的示例，用户可以向SE发起语义查询以查询现在进行户外运动的推荐。如果SE仅具有原始事实，诸如公园的当前户外温度/湿度/风数据，那么无法回答该查询(记住，SPARQL查询处理主要基于模式匹配)。事实上，可以将那些原始事实(作为InputFS)进一步发送给SR以用于使用相关的推理规则进行推理，并且可以推断出高级推断事实(作为InferredFS)，SE可以利用其很好地回答用户的查询。

这部分介绍现有语义操作(诸如语义查询或语义资源发现)如何从语义推理中受益。在以下公开的过程中，仍然涉及先前定义的“逻辑实体”中的一些，诸如FH和RH。除SR之外，SE在系统中也可用，SE是那些语义操作的处理引擎。称为语义用户(SU)的逻辑实体是向SE发送请求以发起语义操作的实体。

一般而言，SU 230可以通过向SE 233发送请求来发起语义操作，该请求可以包括SPARQL查询语句。特别地，SU不知道语义推理功能在SE之后提供帮助。对于SE 233，它可以首先例如基于SU指示的查询范围信息来收集对应SPARQL查询语句的涉及的数据基础(IDB)。IDB的更多示例如下给出：在语义查询的情况下，给定接收到的SPARQL查询语句，通常由查询范围定义要收集的相关语义数据。以oneM2M为例，某个资源下的后代<semanticDescriptor>资源将构成IDB，并且查询将在这个IDB上执行。在进行语义发现的情况下，当通过检查其语义注释(例如，其<semanticDescriptor>子资源)评估给定资源是否应当包括在发现结果中时，这个<semanticDescriptor>子资源将是IDB。但是，手头的IDB可能并不完美，无法为请求提供期望的响应(例如，使用与来自SU 230的SPARQL查询语句中使用的本体不同的本体来描述IDB中的事实)。因而，在这种情况下，语义推理可以提供一定的帮助，以促进在SE 233处处理语义操作处理。

当SE 230决定从SR 232请求帮助时，SE 230或SR 232本身可以决定是否可以充分利用附加事实和规则。如果可以，那么SR可以将那些附加的事实和规则(连同IDB)用于推理，以便识别可以帮助处理来自SU的原始请求的推断事实。语义资源发现在以下过程设计中被用作示例语义操作，这只是为了便于演示，但是，所公开的方法也可以应用于其它语义操作(例如，语义查询、语义混搭等)。

再次，对于扩充的IDB，关键构思是通过利用推理能力，将对IDB进行扩充(通过在推理的帮助下将一些新的推断事实与初始事实集成)。因而，原始查询语句将应用于“扩充的IDB”以生成发现结果。图15的详细描述如下：在步骤221处，SU 230打算发起语义操作，例如语义资源发现操作。例如，SU 230正在寻找监视属于MZ-1的房间的相机。这个发现请求中的SPARQL查询语句可以编写如下：

在步骤222处，SU 230向SE 233发送请求以及SPARQL查询语句和关于应当涉及哪个IDB的信息(如果要求或另外计划的话)，以便发起语义发现操作。使用oneM2M示例，在语义发现的情况下，SU 230可以向CSE(其实现SE)发送发现请求，并指示发现应当从何处开始，例如，这个CSE的资源树上的特定资源<resource-1>。因而，将分别评估<resource-1>的所有子资源，以查看是否应当将其包括在发现结果中。特别地，对于要评估的给定子资源(例如，<resource-2>)，SPARQL查询将应用于存储在<resource-2>的<semanticDescriptor>子资源中的语义数据，以查看是否存在匹配(如果存在，那么<resource-2>将包括在发现结果中)。因而，在这种情况下，当评估<resource-2>时，存储在<resource-2>的<semanticDescriptor>子资源中的语义数据是IDB。

类似地，在语义查询的情况下，SU 230可以向CSE(其实现SE)发送语义查询请求，并指示如何收集相关的语义数据(例如，查询范围)，例如，应当收集特定oneM2M资源<resource-1>下的与语义相关的资源。因而，<resource-1>的后代语义相关的资源(例如，那些<semanticDescriptor>资源)可以一起收集，并且SPARQL查询将应用于那些语义相关资源中的聚合的语义数据，以便产生语义查询结果。因而，在这种情况下，存储在<resource-1>的所有后代语义相关的资源中的数据是IDB。

在步骤222处，基于从SU 230发送的请求，SE 233开始进行语义资源发现处理。使用与图5相关联的示例，<Camera-111>是候选资源之一，并且SU 230可以通过检查其<semanticDescriptor>子资源中的语义数据来评估<Camera-111>是否应当被包括在发现结果中。换句话说，存储在<Camera-111>的<semanticDescriptor>子资源中的数据现在是IDB(表示为IDB-1)。例如，对于语义发现情况，每次开始评估一个特定资源时，都会决定新的IDB并且可以将其仅用于评估这个特定资源。例如，IDB-1可以仅包括以下事实：

·事实-1：相机-111是相机

·事实-2：相机111位于建筑物-1的房间-109中

SE 233还决定处理这个请求是否应当涉及推理。

一般而言，可以有以下可能的方式供SE 233来决定应当涉及推理(这可以通过在SE 233上设置一些本地策略或配置来实现)，包括但不限于：

·如果SE 233无法基于原始IDB-1产生任何结果，那么SE 233可以决定充分利用推理来扩充IDB-1。

·如果SU 230是要求或请求高质量发现的优选用户，那么SE 233可以决定充分利用推理来扩充IDB-1(例如，取决于SU的类型)。

·SE 233还可以被配置为使得只要看到IDB-1中使用的某些本体或感兴趣的术语/概念/特性，SE 233就可以决定充分利用推理来扩充IDB-1。例如，当SE 233检查事实-2并发现事实-2中出现与建筑物号和房间号相关的术语(例如，“建筑物-1”和“房间-109”)时，它可以决定充分利用推理来扩充IDB-1。

如果SE 233决定充分利用推理来扩充IDB-1，那么它还可以联系SR 232。在步骤224处，SE 233将针对推理处理的请求以及与IDB-1相关的信息发送到SR 232，与IDB-1相关的信息将作为用于SR 232处的推理处理的Initial_InputFS。注意的是，现实中SE 233和SR232有可能集成在一起并由同一实体(例如，oneM2M上下文中的同一CSE)实现。SR 232还决定是否应当使用附加FS(作为Addi_InputFS)或RS(作为Initial_RS)进行推理。如图13中所示，关于如何决定应当利用哪个附加的FS和RS的步骤224可以在这里被重新使用。一种扩展是，SR 232不仅可以检查IDB-1中出现的关键词或感兴趣的术语，而且还可以检查步骤221所示的SPARQL语句中出现的关键词或感兴趣的术语。在决定之后，SR 232将检索那些FS和RS。例如，SR 232分别从FH 132检索Addi_InputFS和从RH 136检索Initial_RS。在这个示例中，SR 232发现在事实-2中出现了关键词“位于…中”并且在步骤221中从SU 230发送的SPARQL查询语句中出现了关键词“监视…中的房间”，于是SR 232可以决定可以将关于MZ定义和房间分配的一些有用信息用于推理。因此，Addi_InputFS可以包括以下事实：

·事实-3：建筑物-1的房间-109在“MZ-1”的管理之下

SE 233还决定Initial_RS可以包括以下规则，因为它还包括两个关键词“位于…中”和“在…管理之下”：

·规则-1：IF A位于B中&&B在C的管理之下，那么A监视C中的房间

在步骤226处，基于IDB-1以及收集的Addi_InputFS和Initial_RS，SR 232执行推理处理并产生推断事实(表示为InferredFS-1)。例如，SR 232发现：

·事实-2可以匹配规则-1的IF部分中的部分模式：A位于B中

·事实-3可以匹配规则-1的IF部分中的部分模式：B在C的管理之下

因而，可以推断出新的事实，例如，相机-111监视MZ-1中的房间，其表示为InferredFS-1。在步骤227处，SR 232将InferredFS-1发送回SE 233。在步骤228处，SE 233将InferredFS-1集成到IDB-1中(作为新的IDB-2)，并在IDB-2上应用原始SPARQL语句并产生对应的结果。在该示例中，这意味着在IDB-2上应用SPARQL语句时将存在匹配(由于现在新的推断事实InferredFS-1在IDB-2中，因此它将匹配SPARQL语句中的模式“？devicemonitors-room-in MZ-1”)，因此<Camera-111>的URI将包括在发现结果中)。之后，SE 233完成对<Camera-111>的评估并且可以继续检查要评估的下一个资源。在步骤229处，在SE233完成所有发现处理之后，它将处理结果(在这种情况下就发现结果而言)发送回SU 230。例如，<Camera-111>的URI可以被包括在发现结果(其是处理结果)中并且被发送回SU 230。

语义推理CSF：语义推理CSF可以被视为oneM2M服务层中的新CSF，如图16中所示(可替代地，它也可以是oneM2M TS-0001中定义的现有语义CSF的一部分)。应当理解的是，不同类型的M2M节点可以实现语义推理服务，诸如M2M网关、M2M服务器等。特别地，取决于那些节点的各种/不同的硬件/软件能力，由那些节点实现的语义推理服务的能力也可以是变化的。

图17示出了为FS启用定义的实体的oneM2M示例。例如，事实主机可以是oneM2M系统中的CSE，并且AE/CSE可以是事实提供者或事实消费者或事实修改者。

图18示出了为RS启用定义的实体的oneM2M示例。例如，规则主机可以是oneM2M系统中的CSE，并且AE/CSE可以是规则提供者或规则消费者或规则修改者。

图19示出了涉及个体语义推理操作的实体的oneM2M示例。例如，如果CSE配备了语义推理器，那么它可以提供语义推理服务。此外，AE/CSE可以是推理发起者。如前面所讨论的，在本公开中定义的所涉及实体大多数是逻辑角色。因此，一个物理实体可以担任多个逻辑角色。例如，当CSE具有语义推理能力(例如，如图19所示的SR)并且被要求或请求检索某些FS和RS作为推理操作的输入时，这个CSE也将具有FC和RC的角色，如图17和图18中所示。

图20示出了个体语义推理操作中涉及的实体的另一类型的示例。在这种体系架构中，oneM2M系统主要提供事实和规则。例如，oneM2M CSE可以被视为事实主机或规则主机。oneM2M系统之上可以有另一层(诸如ETSI上下文信息管理(CIM)、W3C物联网(WoT)或开放互连基金会(OCF))，使得用户的语义推理请求可以来自上层。因而，外部CIM/W3C WoT/OCF实体可以配备有语义推理器，并且推理发起者主要是来自CIM/W3C WoT/OCF系统的那些实体。换句话说，那些RI将向语义推理器发送推理请求，语义推理器将进一步联系互相配合实体，并且互相配合实体将通过oneM2M接口从oneM2M实体收集相关的FS和RS(注意的是，FS也可以由其它非oneM2M实体提供，只要oneM2M可以与之交互即可。例如，FS也可以由三元组存储装置提供。)。在oneM2M系统中，可以有两种类型的实体可以处理互相配合，例如，基于IPE的互相配合和基于CSE的互相配合。因而，互相配合实体可以指支持这两种类型的互相配合的CSE或者IPE(其是专用AE)。

图21示出了在推理支持下优化语义操作所涉及的实体的oneM2M示例。例如，如果CSE配备有语义推理器，那么它可以提供语义推理能力，并且如果CSE配备有语义引擎，那么它可以处理其它语义操作(诸如语义资源发现、语义查询等)。此外，AE/CSE可以是触发语义操作的语义用户。注意的是，贯穿这部分中的所有示例，给定的逻辑实体由单个AE或CSE担任，这仅仅是为了便于演示。事实上，在一般情况下，AE或CSE可以担任多个逻辑实体的角色。例如，CSE可以是FH以及RH。另一个示例，CSE可以托管语义推理器和语义引擎两者。另一个示例，CSE可以是推理发起者，并且这个CSE本身也可以配备有语义推理器。

图22示出了在推理支持下优化语义操作所涉及的实体的另一种类型的示例。在这种体系架构中，oneM2M系统主要提供事实和规则。例如，oneM2M CSE可以作为事实主机或规则主机。oneM2M系统之上可以有另一层(诸如CIM、WoT或OCF)，使得用户的语义推理请求可以来自上层。因而，外部CIM/WoT/OCF实体可以配备有语义引擎，并且语义用户主要是来自CIM/WoT/OCF系统的那些实体。类似地，外部CIM/WoT/OCF实体可以配备有语义推理器。一般而言，语义用户将其请求发送到语义引擎以触发某些语义操作。语义引擎还可以联系语义推理器以供推理支持，并且推理器将进一步通过互相配合实体以通过oneM2M接口从oneM2M实体收集相关的FS和RS。注意的是，FS也可以由其它非oneM2M实体提供，只要oneM2M可以与之交互即可。例如，FS也可以由三元组存储装置提供。

下面是图22的更具体示例，用于在ETSI CIM和oneM2M系统之间在推理支持下的语义查询；图23图示了该过程并且详细描述如下：

前提条件0(步骤307)：相机安装在向CSE-1注册的路灯-1上并且<streetCamera-1>是其oneM2M资源表示，并且一些语义元数据也与该资源相关联。例如，语义元数据之一可以是：

·事实-1：<streetCamera-1>安装在路灯-1上

前提条件1(步骤308)：IPE执行语义资源发现并向CIM系统注册相机资源，包括例如街头相机-1。

前提条件2(步骤309)：IPE向CIM注册服务器注册发现的oneM2M相机。类似地，<streetCamera-1>的上下文信息之一是它已安装在路灯-1上(例如，事实-1)

步骤311：CIM应用App-1(其为城市道路监视部门)知道有事故-1，并且具有一些关于事故-1的事实或知识，例如，这个事故的位置：

·事实-2：事故-1的事故位置为“40.079136，-75.288823”

App-1打算从安装在路灯(在事故1中被击中)上的相机收集图像，以便查看相机是否损坏。因而，查询语句可以写为(注意的是，在此语句是使用SPARQL语言编写的，这仅仅是为了便于演示。换句话说，查询语句可以以CIM支持的任何形式编写)：

步骤312：App-1向CIM发现服务发送发现请求，该发现请求关于事故-1中涉及哪个相机，以及关于事故-1的事实-2(诸如其位置)。

步骤313：CIM发现服务无法直接回答发现请求，并且进一步向语义推理器寻求帮助。

步骤314：发现服务将请求和事实-2还有相机的语义信息(包括关于<streetCamera-1>的事实-1)一起发送给语义推理器。换句话说，事实-1和事实-2可以被视为“Initial_InputFS”。

步骤315：语义推理器决定使用关于路灯位置地图的附加事实。例如，由于事实-2仅包括关于事故的地理位置，因此语义推理器可以要求或请求关于路灯的更多信息，以便决定涉及哪个路灯。例如，事实-3是关于路灯-1的附加事实。

·事实-3：路灯-1的事故位置为“40.079236，-75.288623”

步骤316：语义推理器进一步进行语义推理并产生一些新的事实(事故-1中涉及<streetCamera-1>)。例如，如下所示的规则-1可以被用于推导事故-1中涉及路灯-1的新事实(推断事实-1)。

·规则-1：IF A具有位置坐标-1并且B具有位置坐标-2，并且距离(坐标-1，坐标-2)<20米，THEN B中涉及A

·推断事实-1：事故-1中涉及路灯-1

另外，利用推断事实-1和事实-1，可以通过使用以下规则(规则-2)来执行另一种推理，并且可以推导另一个推断事实(例如，推断事实-2)：

·规则-1：IF B中涉及A并且C安装在A上，THEN B中涉及C

·推断事实-2：事故-1中涉及<streetCamera-1>

步骤317：新事实被发送回CIM发现服务。步骤318：使用新事实，CIM发现服务现在可以回答来自App-1的查询，因为推断事实-2示出<streetCamera-1>是事故-1中涉及的相机。步骤319：App-1被告知事故-1中涉及<streetCamera-1>。步骤320：App-1进一步联系CIM注册服务器以检索<streetCamera-1>的图像并且注册服务器将进一步请求oneM2M IPE从oneM2M系统中的<streetCamera-1>资源检索图像。

<facts>资源定义：给定的FS可以指不同类型的知识。首先，FS可以指本体，该本体描述给定用例(例如，与图5相关联的智能城市用例，其中定义了许多域概念/类及其关系，诸如医院、城市消防部门、建筑物、房间等)的域知识。因而，这种类型的FS可以被实施为oneM2M<ontology>资源。其次，FS还可以指关于系统中资源/实体/事物的语义注释。仍然使用与图5相关联的先前示例，FS可以是用于相机-111的语义注释，它部署在建筑物-1的房间-109中。因而，这种类型的FS可以被实施为oneM2M<semanticDescriptor>资源。

FS也可以指与特定实例相关的事实。仍然使用与图5相关联的先前示例，FS可以描述医院的当前管理区定义，诸如其建筑物/房间布置/分配信息(例如，管理区MZ-1包括用于存储血液测试样本的房间，例如，建筑物-1中的房间-109、建筑物-3中的房间-117等)。注意的是，对于这种类型的事实，它可以单独存在于系统中，例如，不必作为其它资源/实体/事物的语义注释。因而，定义了一种新类型的oneM2M资源(称为<facts>)来存储此类FS。注意的是，可以使用不同的名称来对其命名，只要它具有相同的目的即可。<facts>的资源结构如图24中所示。如果这个资源可以被用于存储数据的语义类型，那么FS也可以指<contentInstance>资源。此外，更一般地，FS可以指由oneM2M定义的任何未来新资源类型，只要它们可以存储数据的语义类型即可。

上面的<facts>资源可以包括表2中指定的一个或多个子资源。

表2.<facts>资源的子资源

上面的<facts>资源可以包括表3中指定的一个或多个属性。

表3.<facts>资源的属性

注意的是，如下面介绍的对<facts>资源的CRUD操作将是本文介绍的关于启用语义推理数据的相关过程的oneM2M示例。注意的是，由于<semanticDescriptor>资源还可以被用于存储事实(例如，使用“descriptor”属性)，因此诸如factType、rulesCanBeUsed、usedRules、originalFacts之类的属性也可以用作现有<semanticDescriptor>资源的新属性，用于支持语义推理目的。例如，假设<SD-1>和<SD-2>是<semanticDescriptor>资源的类型，并且是<CSE-1>的语义注释。<SD-1>可以是<CSE-1>的原始语义注释。相比之下，<SD-2>是<CSE-1>的附加语义注释。例如，<SD-2>的“factType”可以指示存储在<SD-2>资源的“descriptor”属性中的三元组/事实是基于语义推理操作的推理结果(例如，推断事实)。换句话说，<SD-2>中存储的语义注释是通过语义推理生成的。类似地，<SD-2>的rulesCanBeUsed、usedRules、originalFacts属性还可以指示关于如何生成存储在<SD-2>中的事实(基于哪个inputFS和推理规则)以及可以如何使用存储在<SD-2>中的事实进行其它推理操作的详细信息。

Create<facts>：用于创建<facts>资源的过程。

表4.<facts>CREATE

Retrieve<facts>：用于检索<facts>资源的属性的过程。

表5.<facts>RETRIEVE

Update<facts>：用于更新<facts>资源的属性的过程。

表6.<facts>UPDATE

Delete<facts>：用于删除<facts>资源的过程。

表7.<facts>DELETE

<factRepository>资源定义：一般而言，<facts>资源可以存储在任何地方，例如，作为<AE>或<CSEBase>资源的子资源。可替代地，可以将新的<factRepository>定义为新的oneM2M资源类型，其可以是存储多个<facts>的中心(hub)，使得更容易找到所需或所请求的事实。<factRepository>资源可以是<CSEBase>或<AE>资源的子资源。<factRepository>的资源结构在图25中示出。

<factRepository>资源应包含表8中指定的子资源。

表8.<factRepository>资源的子资源

上面的<factRepository>资源可以包括表9中指定的属性中的一个或多个。

表9.<factRepository>资源的属性

Create<factRepository>：用于创建<factRepository>资源的过程。

表10.<factRepository>CREATE

Retrieve<factRepository>：用于检索<factRepository>资源的过程。

表11.<factRepository>RETRIEVE

Update<factRepository>：用于更新现有<factRepository>资源的过程。

表12.<factRepository>UPDATE

Delete<factRepository>：用于删除现有<factRepository>资源的过程。

表13.<factRepository>DELETE

<reasoningRules>资源定义：定义了新类型的oneM2M资源(称为<reasoningRules>)来存储RS，该RS被用于存储(用户定义的)推理规则。注意的是，可以使用不同的名称来命名，只要它具有相同的目的即可。<reasoningRules>的资源结构如图26中所示。

上面的<reasoningRules>资源可以包括表14中指定的子资源中的一个或多个。

表14.<reasoningRules>资源的子资源

上面的<reasoningRules>资源可以包括表15中指定的属性中的一个或多个。

表15.<reasoningRules>资源的属性

下面是如何使用RIF表示推理规则的示例。考虑本公开中使用的以下推理规则：

·规则-1：IF A位于B中&&B在C的管理之下，THEN A监视C中的房间

规则-1可以写为以下RIF规则(粗体字是RIF语法定义的关键词，并且RIF规范的更多细节参见RIF Primer，https://www.w3.org/2005/rules/wiki/Primer[12])：

可以通过以下五个解释来提供对以上规则的解释。解释1：以上规则基本上遵循以If...Then形式的抽象语法。解释2：可以使用两个运算符Group和Document来编写RIF中的规则。Group用于在RIF文档中对规则集划界或将规则集分组在一起。文档可以包含多个组或者仅一个组。类似地，组可以由单个规则组成，但是它们一般旨在将多个规则分组在一起。必需具有明确的Document运算符，因为RIF文档可能会导入其它文档，因此本身可能是多文档对象。出于实际目的，知道一般在文档的开头使用Document运算符，然后使用前缀声明和一组或多组规则就足够了。

解释3：谓语常量(如“位于…中”)不能仅按原样使用，但是可以消除歧义。这种消除歧义解决以下问题：这个规则中使用的常量来自多于一个源并且可以具有不同的语义含义。在RIF中，通过编写前缀声明Prefix(ns<ThisIRI>)，使用IRI和前缀声明的一般形式来实现消除歧义。然后，可以使用字符串ns:name在规则中消除常量名称的歧义。例如，谓语“位于…中”是由示例本体A(带有前缀“exA”)定义的谓语，而谓语“在…管理之下”是由另一个示例本体B(带有前缀“exB”)定义的谓语，并且谓语“监视…中的房间”是由另一个示例本体C(带有前缀“exC”)定义的谓语。

解释4：类似地，对于以“？”开头的变量(例如，？Camera)，还必需通过使用特殊符号“#”(它等于如RDF模式中定义的谓语“是…的类型”)来定义哪种实例类型可以作为那个变量的输入。例如，“？Camera#exA:Camera”意味着仅本体A中定义的类Camera的实例可以用作？Camera变量的输入。解释5：以上规则可以包括连词，并且在RIF中，连词以前缀表示重写，例如二进制A和B被写为And(A B)。

注意的是，下面介绍的对<reasoningRules>资源的CRUD操作是本文介绍的有关RS启用的相关过程的oneM2M示例。

Create<reasoningRules>：用于创建<reasoningRules>资源的过程。

表16.<reasoningRules>CREATE

Retrieve<reasoningRules>：用于检索<reasoningRules>资源的属性的过程。

表17.<reasoningRules>RETRIEVE

Update<reasoningRules>：用于更新<reasoningRules>资源的属性的过程。

表18.<reasoningRules>UPDATE

Delete<reasoningRules>：用于删除<reasoningRules>资源的过程。

表19.<reasoningRules>DELETE

<ruleRepository>资源定义：一般而言，<reasoningRules>资源可以存储在任何地方，例如，作为<AE>或<CSEBase>资源的子资源。可替代地，可以将新的<ruleRepository>定义为新的oneM2M资源类型，其可以作为存储多个<reasoningRules>的中心，使得更容易找到所需或所请求的规则。<ruleRepository>资源可以是<CSEBase>或<AE>资源的子资源。<ruleRepository>的资源结构在图27中示出。

<ruleRepository>资源可以包括表8中指定的一个或多个子资源。

表20.<ruleRepository>资源的子资源

上面的<ruleRepository>资源可以包括表9中指定的属性中的一个或多个。

表21.<ruleRepository>资源的属性

Create<ruleRepository>：用于创建<ruleRepository>资源的过程。

表22.<ruleRepository>CREATE

Retrieve<ruleRepository>：用于检索<ruleRepository>资源的过程。

表23.<ruleRepository>RETRIEVE

Update<ruleRepository>：用于更新现有的<ruleRepository>资源的过程。

表24.<ruleRepository>Update

Delete<ruleRepository>：用于删除现有的<ruleRepository>资源的过程。

表25.<ruleRepository>DELETE

<semanticReasoner>资源定义：公开了称为<semanticReasoner>的新资源，其用于暴露语义推理服务。<semanticReasoner>的资源结构在图28中示出。

如果CSE具有语义推理能力，那么它可以在其上(例如，在<CSEBase>下)创建<semanticReasoner>资源以支持语义推理处理。

上面的<semanticReasoner>资源可以包括表26中指定的子资源中的一个或多个。

表26.<semanticReasoner>资源的子资源

上面的<semanticReasoner>资源可以包括表27中指定的属性中的一个或多个。

表27.<semanticReasoner>资源的属性

可替代地，暴露语义推理的另一种方式是使用现有的<CSEBase>或<remoteCSE>资源。因而，表27中所示的属性可以是<CSEBase>或<remoteCSE>资源的新属性。<CSEBase>可以有几种获得(例如，接收)语义推理请求的方式：1)<reasoningPortal>资源可以是<CSEBase>或<remoteCSE>资源的新子虚拟资源，用于接收与触发这项工作中定义的语义推理操作相关的请求；或2)代替定义新资源，也可以直接朝着<CSEBase>发送来自RI的请求，其中可以在请求消息中定义触发(例如，可以定义称为“reasoningIndicator”的新参数以包括在请求消息中)。

Create<semanticReasoner>：用于创建<semanticReasoner>资源的过程。

表28.<semanticReasoner>CREATE

Retrieve<semanticReasoner>：用于检索<semanticReasoner>资源的过程。

表29.<semanticReasoner>RETRIEVE

Update<semanticReasoner>：用于更新现有<semanticReasoner>资源的过程。

表30.<semanticReasoner>UPDATE

Delete<semanticReasoner>：用于删除现有<semanticReasoner>资源的过程。

表31.<semanticReasoner>DELETE

<reasoningPortal>资源定义：<reasoningPortal>是虚拟资源，因为它不具有表示。它是<semanticReasoner>资源的子资源。当UPDATE操作被发送到<reasoningPortal>资源时，它触发语义推理操作。

一般而言，出于以下目的，发起方可以向这个<reasoningPortal>资源发送请求，这将在下面公开。在第一个示例中，该请求可以是触发一次性推理操作。在这个示例中，请求中可以携带以下信息：a)在这个推理操作中要使用的事实、b)在推理操作中要使用的推理规则、c)指示这是用于一次性推理操作的推理类型，或d)前面各部分中列出的任何其它信息。在第二示例中，请求可以触发连续推理操作。在这个第二示例中，请求中可以携带以下信息：a)推理操作中要使用的事实、b)推理操作中要使用的推理规则、c)指示这是用于连续推理操作的推理类型，或d)用于创建<reasoningJobInstance>资源的任何其它信息。例如，continuousExecutionMode是<reasoningJobInstance>资源中的属性之一。因此，请求还可以携带可以用于设置这个属性的相关信息。在第三示例中，请求可以是针对现有的推理作业触发新的推理操作。在这个第三示例中，可以在请求中携带以下信息：jobID：现有的<reasoningJobInstance>资源的URI。

此外，对于要在请求中携带的信息，例如要使用的事实和推理规则，有多种方式在请求中携带它们：1)事实和推理规则可以在请求的content参数中携带；或2)事实和推理规则可以在请求的新参数中携带。示例新参数是Facts(事实)参数和Rules(规则)参数。对于事实参数，它可以携带要在推理操作中使用的事实。对于规则参数，它可以携带要在推理操作中使用的推理规则。

对于“Facts”参数，它可以使用以下方式包括关于事实的信息：

·情况1：Facts参数可以直接包括事实数据，诸如RDF三元组。

·情况2：Facts参数可以还包括用于存储要使用的事实的一个或多个URI。

对于“Rules”参数，它可以使用以下方式包括关于事实的信息：

·情况1：Rules参数可以包括存储要使用的规则的一个或多个URI。

·情况2：Rules参数可以直接携带要使用的推理规则的列表。

·情况3：Rules参数可以是字符串值，其指示特定的标准SPARQL蕴含机制。(注意的是，SPARQL蕴含是使用由不同蕴含机制定义的标准推理规则的一种类型的语义推理)。例如，如果Rules＝“RDFS”，那么意味着将使用RDFS蕴含机制定义的推理规则。

对于实施方式选择，可以仅实现上述情况之一，或者可以同时实现那些情况。对于后一种情况，可以定义两个新参数，称为typeofFactsRepresentation和typeofUseReasoning，它们可以是请求中包括的参数并且可以具有示例性值，这些值可以是如下所示的指示符：

·typeofFactsRepresentation＝1，Facts参数存储URI。

·typeofFactsRepresentation＝2，Facts参数存储事实的列表，例如要使用的RDF三元组。

·typeofRulesRepresentation＝1，Rules参数存储(一个或多个)URI的列表。

·typeofRulesRepresentation＝2，Rules参数存储推理规则的列表。

·typeofRulesRepresentation＝3，Rules参数存储字符串值，该字符串值指示标准蕴含机制。

当由托管CSE创建父<semanticReasoner>资源时，创建<reasoningPortal>资源。Create操作不经由Mca、Mcc或Mcc'适用。

Retrieve操作可能不适用于<reasoningPortal>。

Update<reasoningPortal>：Update操作用于触发语义推理操作。对于连续推理操作，它可以按以下方式利用<reasoningPortal>。在第一种方式中，使用<reasoningPortal>UPDATE操作。对于这第一种方式，可以在请求中携带推理类型参数，以指示这个请求要求创建连续推理操作。在第二种方式中，使用<reasoningPortal>Create操作。

表32A.<reasoningPortal>UPDATE

以下是用于处理表32A中所示的<reasongingPortal>UPDATE操作的替代版本。例如，在这个版本中，事实和推理规则在请求中的Facts和Rules参数中携带。同时，为了简化，它不考虑添加附加事实和规则。

表32B.<reasoningPortal>UPDATE的简化版本

Delete<reasoningPortal>：当由托管CSE删除父<semanticReasoner>资源时，应删除<reasoningPortal>资源。Delete操作不经由Mca、Mcc或Mcc'适用。

<reasoningJobInstance>资源定义：定义新类型的oneM2M资源(称为<reasoningJobInstance>)以描述特定的推理作业实例(它可以是一次性推理操作，或者是连续推理操作)。注意的是，可以用不同的名称来命名，只要它具有相同的目的即可。

注意的是，以下可以是进行连续推理作业的替代方法。在第一种方式中，发起方可以向CSE的<semanticReasoner>(或向<CSEBase>资源)发送请求，以便如果这个CSE可以支持语义推理能力，那么创建<reasoningJobInstance>资源。在第二种方式中，发起方可以向<semanticReasoner>资源的<reasoningPortal>发送CREATE请求，以便创建<reasoningJobInstance>资源(或者它可以向<reasoningPortal>发送UPDATE请求，但是包括在请求中的reasoning type参数可以指示这是为了创建连续推理操作)。

<reasoningJobInstance>的资源结构在图29中示出。<reasoningJobInstance>资源可以包括表33中指定的子资源中的一个或多个。

表33.<reasoningJobInstance>资源的子资源

上面的<reasoningJobInstance>资源可以包括表34中指定的属性中的一个或多个。

表34.<reasoningJobInstance>资源的属性

用于创建<reasoningJobInstance>资源的过程。

表35.<reasoningJobInstance>CREATE

Retrieve<reasoningJobInstance>：用于检索<reasoningJobInstance>资源的属性的过程。

表36.<reasoningJobInstance>RETRIEVE

Update<reasoningJobInstance>：用于更新<reasoningJobInstance>资源的属性的过程。

表37.<reasoningJobInstance>UPDATE

Delete<reasoningJobInstance>：用于删除<reasoningJobInstance>资源的过程。

表38.<reasoningJobInstance>DELETE

<reasoningResult>资源定义：定义新类型的oneM2M资源(称为<reasoningResult>)以存储推理结果。注意的是，可以用不同的名称来命名，只要它具有相同的目的即可。<reasoningResult>的资源结构在图30中示出。

上面的<reasoningResult>资源可以包括表39中指定的子资源中的一个或多个。

表39.<reasoningResult>资源的子资源

上面的<reasoningResult>资源可以包括表40中指定的属性中的一个或多个。

表40.<reasoningResult>资源的属性

Create操作不适用于<reasoningResult>。<reasoningResult>资源由托管CSE自动生成，该托管CSE在对<reasoningJobInstance>父资源表示的推理作业执行语义推理处理时具有语义推理器能力。

Retrieve<reasoningResult>：用于检索<reasoningResult>资源的属性的过程。

表41.<reasoningResult>RETRIEVE

Retrieve操作不适用于<reasoningResult>。

Delete<reasoningResult>：用于删除<reasoningResult>资源的过程。

表42.<reasoningResult>DELETE

<jobExecutionPortal>资源定义：<jobExecutionPortal>是虚拟资源，因为它不具有表示并且具有如先前定义的<reasoningPortal>资源的类似功能。它是<reasoningJobInstance>资源的子资源。当属性continuousExecutionMode的值设置为“当RI触发作业执行时”并且UPDATE操作被发送到<jobExecutionPortal>资源时，它触发与父<reasoningJobInstance>资源对应的语义推理执行。

Create<jobExecutionPortal>：当创建父<reasoningJobInstance>资源时，应当创建<reasoningPortal>资源。

Retrieve<jobExecutionPortal>：Retrieve操作不适用于<reasoningPortal>。

Update<jobExecutionPortal>：Update操作用于触发语义推理执行。与向具有jobID的<reasoningPortal>资源发送更新请求相比，这是一种替代方案。

表43A.<jobExecutionPortal>UPDATE

以下是用于处理表43A中所示的<jobExecutionPortal>UPDATE操作的简化版本或替代版本。例如，为了简化，它不考虑提供附加事实和规则。

表43B.<jobExecutionPortal>UPDATE的简化版本

Delete<jobExecutionPortal>：当托管CSE删除父<reasoningJobInstance>资源时，应删除<jobExecutionPortal>资源。删除操作不经由Mca、Mcc或Mcc'适用。

用于语义推理相关过程的oneM2M示例与启用个体语义推理处理和提高另一个的有效性相关联地引入。这部分介绍本文公开的方法的几个oneM2M示例。

在图13中公开了一次性推理操作的OneM2M示例。在这种场景中，AE-1(作为RI)已经识别出一些感兴趣的InputFS(<facts-1>)和RS(<reasoningRules-1>)，并希望在CSE-1(作为SR)处发起一次性推理操作，以便发现一些新知识/事实。图31图示了用于一次性推理操作的oneM2M过程，并且详细描述如下。

前提条件(步骤340)：AE-1知道CSE-1(其充当SR)的存在，并且在CSE-1上创建了<semanticReasoner>资源。通过发现，AE-1识别出感兴趣的CSE-2上的<facts-1>资源(<facts-1>将成为Initial_InputFS)和CSE-3上的一些<reasoningRules-1>(<reasoningRules-1>将成为Initial_RS)的集合。

步骤341：AE-1打算使用<facts-1>和<reasoningRules-1>作为输入，以触发CSE-1处的推理以发现一些新知识。

步骤342：AE-1向CSE-1上的<reasoningPortal>虚拟资源发送推理请求，以及关于Initial_InputFS和Initial_RS的信息。例如，可以通过请求中新公开的Facts和Rules参数来描述要使用的事实和规则。

步骤343：基于从AE-1发送的信息，CSE-1从CSE-2检索<facts-1>并从CSE-3检索<reasoningRules-1>。

步骤344：除了由AE-1提供的输入之外，可选地，CSE-1还可以决定CSE-2上的<facts-2>和CSE-3上的<reasoningRules-2>也应当被利用。

步骤345：CSE-1从CSE-2检索附加的FS(例如，<facts-2>)，并从CSE-3检索附加的RS(例如，<reasoningRules-2>)。

步骤346：利用所有的InputFS(例如，<facts-1>和<facts-2>)和RS(例如，<reasoningRules-1>和<reasoningRules-2>)，CSE-1将执行推理处理并产生推理结果。

步骤347：SR 232将推理结果发送回AE-1。此外，如本文中所介绍的，SR 232还可以创建<reasoningResult>资源以存储推理结果。

在图14中公开了连续推理操作的OneM2M示例。在这种场景中，AE-1(作为RI)已经识别出一些感兴趣的InputFS(<facts-1>)和RS(<reasoningRules-1>)，并希望在CSE-1(作为SR)处发起连续推理操作以发现一些新知识(术语事实和知识在本文中可以被同义使用)。图32图示了用于连续推理操作的oneM2M示例过程并且详细描述如下。

前提条件(步骤350)：AE-1知道CSE-1(充当SR)的存在并且在CSE-1上创建了<semanticReasoner>资源。通过发现，AE-1已经识别出感兴趣的CSE-2上的<facts-1>资源(<facts-1>将成为Initial_InputFS)和CSE-3上的一些<reasoningRules-1>(<reasoningRules-1>将为Initial_RS)的集合。

步骤351：AE-1打算使用<facts-1>和<reasoningRules-1>作为输入来触发CSE-1上的连续推理操作。

步骤352：AE-1向<semanticReasoner>资源的<reasoningPortal>子资源发送CREATE请求连同关于Initial_InputFS和Initial_RS的信息，以及用于要创建的<reasoningJobInstance>的一些其它信息，以创建<reasoningJobInstance>资源。可替代地，另一个可能的实施方式是AE-1可以向<CSEBase>或<semanticReasoner>资源发送CREATE请求。

步骤353：基于从AE-1发送的信息，CSE-1从CSE-2检索<facts-1>并从CSE-3检索<reasoningRules-1>。CSE-1还对那两个资源进行订阅。

步骤354：除了由AE-1提供的输入之外，可选地，CSE-1还可以决定CSE-2上的<facts-2>和CSE-3上的<reasoningRules-2>也应当被利用。

步骤355：CSE-1从CSE-2检索附加的FS(例如，<facts-2>)并从CSE-3检索附加的RS(例如，<reasoningRules-2>)。CSE-1还对这两个资源进行订阅。

步骤356：利用所有InputFS(例如，<facts-1>和<facts-2>)和RS(例如，<reasoningRules-1>和<reasoningRules-2>)，CSE-1将在<semanticReasoner>资源下(或其它优选位置)创建<reasoningJobInstance-1>资源。例如，reasoningType属性将被设置为“连续推理操作”并且continuousExecutionMode属性将被设置为“当相关的FS/RS改变时”。然后，它执行推理处理并产生推理结果。结果可以存储在<reasoningJobInstance-1>的reasoningResult属性中或者存储在新的<reasoningResult>类型的子资源中。

步骤357：SR 232将推理结果发送回AE-1。

步骤358。由于先前在步骤3中建立的订阅，对<facts-1>、<facts-2>、<reasoningRules-1>和<reasoningRules-2>的任何改变都会触发对CSE-1的通知。

步骤359。只要CSE-1接收到通知，它就将通过使用相关FS和RS的最新值执行<reasoningJobInstance-1>的新推理处理。新的推理结果也将发送到AE-1。

在图15中公开了过程的OneM2M示例。在这种场景中，AE-1(作为SU)打算在CSE-1(作为SE)中进行语义资源发现。在资源发现处理期间，CSE-1还可以利用来自CSE-2的推理支持，以便获得优化的发现结果。图33A图示了用于扩充由推理支持的IDB的示例oneM2M过程并且详细描述如下：

步骤361：AE-1打算发起语义资源发现操作。

步骤362：AE-1向CSE-1的<CSEBase>发送请求以便发起语义发现操作，其中包括SPARQL查询语句。

步骤363：基于从AE-1发送的请求，CSE-1开始进行语义资源发现处理。特别地，CSE-1现在开始通过检查<AE-2>的<semanticDescriptor-1>子资源来评估是否将<AE-2>资源包括在发现结果中。但是，<semanticDescriptor-1>中的当前数据不能与从AE-1发送的SPARQL查询语句匹配。因此，CSE-1决定为处理该请求应当进一步涉及推理。

步骤364：CSE-1向CSE-2(其具有语义推理能力)上的<reasoningPortal>资源发送请求以及存储在<semanticDescriptor-1>中的信息，以要求进行推理处理。

步骤365：CSE-2进一步决定应当为这个推理处理添加附加FS和RS。例如，CSE-1分别从CSE-3检索<facts-1>和从CSE-4检索<reasoningRules-1>。

步骤366：基于<semanticDescriptor-1>(作为IDB)中存储的信息以及附加的<facts-1>和<reasoningRules-1>，CSE-1执行推理处理并产生推断事实(表示为InferredFS-1)。

步骤367：CSE-2将InferredFS-1发送回CSE-1。

步骤368：CSE-1将InferredFS-1与<semanticDescriptor-1>中存储的数据集成，并将原始SPARQL语句应用于所集成的数据并获得匹配。作为结果，<AE-2>将包括在发现结果中。CSE-1将继续评估<CSEBase>下的下一个资源，直到它完成所有资源发现处理为止。

步骤369：CSE-1将最终发现结果发送回AE-1。

下面讨论的是图33A的替代过程，其可以被视为图33A中所示过程的简化版本。在这种场景中，AE-1(作为SU)可以向CSE-1发送请求并打算进行语义资源发现。注意的是，在此，语义发现仅仅是示例，并且它可以是另一种语义操作，诸如语义查询等。特别地，在这个过程中，可以由CSE-1实现语义引擎(SE)和语义推理器(SR)。因而，在资源发现处理期间，CSE-1还可以利用推理支持以便获得优化的发现结果。

图33B图示了图33A的替代过程并且详细描述如下。在步骤371处：AE-1打算发起语义资源发现操作。在步骤372处：AE-1可以向CSE-1的<CSEBase>发送请求以便发起语义发现操作，其中包括SPARQL查询语句。AE-1还可以指示是否可以使用语义推理。例如，这个请求中可以携带称为useReasoning的新参数。关于如何使用这个useReasoning参数，有多种不同方式，诸如以下情况：

·情况1：第一种实施方式是useReasoning可以为0或1。当useReasoning＝1时，意味着AE-1请求CSE-1在SPARQL处理期间应用语义推理，而useReasoning＝0(或请求中不存在useReasoning参数时)意味着AE-1不请求CSE-1应用语义推理。在这种情况下，使用哪些推理规则完全由语义引擎或语义推理器(例如，在这种情况下为CSE-1)决定。

·情况2：第二种实施方式是useReasoning可以是URI(或URI的列表)，URI引用存储要使用的推理规则的一个或多个特定<reasoningRule>资源。

·情况3：第三种实施方式是useReasoning可以直接存储AE-1希望CSE-1在SPARQL处理期间使用的推理规则的列表。

·情况4：第四种实施方式是useReasoning可以是字符串值，其指示特定的标准SPARQL蕴含机制。(注意的是，SPARQL蕴含是使用由不同蕴含机制定义的标准推理规则的一种类型的语义推理)。例如，如果useReasoning＝“RDFS”，那么意味着AE-1在处理期间请求CSE-1应用由RDFS蕴含机制定义的推理(在本文中其可以被称为蕴含)规则。

对于实施方式选择，可以仅实现上述四种情况之一，或者可以同时实现那四种情况。对于后一种情况，可以定义称为typeofRulesRepresentation的新参数，它是包括在请求中的参数并且可以具有以下值和含义：

·typeofRulesRepresentation＝1，useReasoning参数可以为0或1。

·typeofRulesRepresentation＝2，useReasoning参数存储一个或多个URI。

·typeofRulesRepresentation＝3，useReasoning存储推理规则的列表。

·typeofRulesRepresentation＝4，useReasoning存储字符串值，该字符串值指示标准的SPARQL蕴含机制。

在步骤373处：基于从AE-1发送的请求，CSE-1开始进行语义资源发现处理。例如，CSE-1现在开始通过检查<AE-2>的<semanticDescriptor-1>子资源来评估<AE-2>资源是否应当包括在发现结果中。特别地，如果CSE-1具有应用语义推理的能力，那么CSE-1可以首先决定是否应当应用语义推理。因而，它还可以基于步骤372中定义的不同情况而具有以下操作：

·情况1：当useReasoning＝1时，CSE-1可以决定要使用的推理规则的适当集合。

·情况2：当useReasoning包括一个或多个URI时，CSE-1可以检索存储在由这个参数引用的相关<reasoningRule>资源中的推理规则。

·情况3：当useReasoning直接存储推理规则的列表时，CSE-1可以使用这些推理规则进行推理。

·情况4：当useReasoning是字符串值时，它可以指示特定的标准SPARQL蕴含机制。然后，CSE-1可以在处理期间使用由对应的标准蕴含机制定义的推理规则。

在AE-1询问某种类型的推理而CSE-1不具有这种能力的情况下，不能应用语义推理操作。例如，如果AE-1向CSE-1提供错误的URI，那么CSE-1不能应用推理，因为CSE-1可能无法基于这个错误的URI检索推理规则。

在步骤374处：基于<semanticDescriptor-1>中存储的信息和所应用的推理规则，CSE-1可以首先执行推理处理并产生推断事实。然后，CSE-1可以将推断事实与<semanticDescriptor-1>中存储的原始数据集成，然后对集成的数据应用原始SPARQL语句。因此，<AE-2>可以包括在发现结果中。然后，CSE-1可以继续评估下一个候选资源，直到发现操作完成为止。在步骤375处：CSE-1可以将最终发现结果发送回AE-1。

在图34中提供了GUI界面，该GUI界面可以被用于让用户查看、配置或触发语义推理操作。例如，通过使用图34中设计的UI，它允许用户指示用户希望哪些事实和哪些规则用于推理操作。例如，这些事实和规则可以存储在先前定义的<facts>或<reasoningRules>资源中。用户还可以指示将语义推理规则(例如，推断事实)递送到何处。可以实现用于用默认值配置或编程那些参数的用户界面，以及用于启用或禁用用于语义推理支持的某些特征的控制开关。

下表44提供了到目前为止使用的术语的描述。

表44

注意的是，所公开的主题可以适用于其它服务层。此外，本公开使用SPARQL作为用于指定用户的要求/约束的示例语言。但是，所公开的主题可以适用于使用除SPARQL以外的其它语言编写用户的要求或约束的其它情况。如本文所公开的，“用户”可以是另一个设备，诸如服务器或移动设备。

在不以任何方式不当地限制本文出现的权利要求的范围、解释或应用的情况下，本文公开的示例中的一个或多个的技术效果是提供对语义推理支持操作的调整。一般而言，本文公开的是提供触发服务层处的推理操作的方式的系统、方法或装置。当语义操作被触发时(诸如语义资源发现或语义查询)，在语义操作的处理(例如，语义资源发现或语义查询)期间，语义推理可以被充分利用作为后台支持(参见图15)而没有用户设备知道(例如，自动而不提醒用户设备，诸如AE或CSE)。换句话说，对于给定的接收方(例如，CSE)，当其从客户端接收到针对语义操作(诸如语义发现或查询)的请求时，接收方可以处理那些请求。特别地，在处理期间，接收方还可以利用语义推理能力来优化处理(例如，以使发现结果更准确)。

图35示出了图6的oneM2M示例。可以看出，在oneM2M中定义了新的语义推理功能(SRF)，以下是SRF的关键特征以及SRF可以支持的不同类型功能的详细描述。图36图示了图35的替代方案。图36是图35的替代图。<facts>资源和<rules>资源在SRF的盒子之外(因为<facts>、<rules>是资源，而SRF是功能)。

特征-1：下面讨论启用语义推理相关数据。特征-1的功能可以是通过使语义推理相关数据跨oneM2M系统中的不同实体可发现、可发布(例如，可共享)来启用语义推理相关数据(指事实和推理规则)(在图35中由箭头381图示)。语义推理相关数据可以是事实集(FS)或规则集(RS)。FS是指事实的集合。例如，每个RDF三元组可以描述事实，因而存储在<semanticDescriptor>资源中的RDF三元组的集合被视为FS。一般而言，FS可以被用作语义推理处理的输入(例如，输入FS)，或者它可以是作为语义推理处理的结果的推断事实(例如，推断FS)的集合。RS是指语义推理规则的集合。

为了执行特定的语义推理处理A，可以使用以下两种类型的数据输入：1)输入FS(表示为inputFS)，以及2)RS。

语义推理处理A的输出可以包括：推断FS(表示为inferredFS)，这是推理处理A的语义推理结果。

注意的是，由推理处理A生成的inferredFS未来还可以用作另一个语义推理处理B的inputFS。因此，在以下描述中，如果适用，将使用通用术语FS。

事实不限于普通的oneM2M资源的语义注释(例如，存储在<semanticDescriptor>资源中的RDF三元组)。事实可以指在oneM2M系统中可用的任何有价值的信息或知识并且其他人可以访问。例如，存储在oneM2M<ontology>资源中的本体描述可以是FS。另一种情况，FS也可以是一条单独的信息(诸如在图5中的前一个用例中讨论的描述医院房间分配记录的RDF三元组)，并且这种FS没有描述本体或没有描述为另一个资源的语义注释(例如，描述医院房间分配记录的FS可以单独存在，而不必作为其它资源的语义注释)。

关于RS，由于oneM2M系统被设计为支持跨不同域的应用的水平平台，因此用户有设计许多定制的(或用户定义的)语义推理规则以支持各种应用的需要。因而，可以使各种用户定义的RS在oneM2M系统中可用并且不被其他人访问或共享。注意的是，此类用户定义的语义推理规则可以提高系统灵活性，因为在许多情况下，用户定义的推理规则可以仅在本地或临时使用(例如，以定义本体中两个类之间的新的或临时关系)，而不必修改本体定义。

总体而言，特征-1涉及通过适当的oneM2M资源启用发布或发现或共享与语义推理相关的数据(包括FS和RS两者)。特征-1的一般流程是，oneM2M用户(作为发起方)可以将请求发送到某些接收方CSE，以便通过对应的CRUD操作发布、发现、更新或删除FS相关资源或RS相关资源。一旦处理完成，接收方CSE就可以将响应发送回发起方。

特征-2：以下公开了利用背景语义推理支持来优化其它语义操作：如与特征-1相关联的前一部分中所呈现的，oneM2M系统中支持的现有语义操作(例如，语义资源发现和语义查询)在没有语义推理支持的情况下可能无法产生期望的结果。SRF的特征-2的功能是充分利用语义推理作为“后台支持”来优化其它语义操作(图35中的箭头382所示)。在这种情况下，用户触发或发起特定的语义操作(例如，语义查询)。在这个操作的处理期间，可以在后台进一步触发语义推理，但是这对用户是完全透明的。例如，用户可以通过将SPARQL查询提交给SPARQL查询引擎来发起语义查询。所涉及的RDF三元组(表示为FS-1)有可能无法直接回答SPARQL查询。因而，SPARQL引擎还可以求助于SR，SR将进行语义推理处理。如果FS-1(作为inputFS)不足(例如，基于某些访问权限)，那么SR应确定并选择适当的推理规则集(作为RS)以及任何附加FS。最后，根据inferredFS的语义推理结果将被递送到SPARQL引擎，该引擎可以进一步被用于回答/匹配用户的SPARQL查询语句。

仍使用图5中所呈现的用例，讨论以下两个示例，其示出SRF如何可以解决oneM2M系统中那两个示例中提出的问题。通过添加<semanticDescriptor>资源作为其子资源，用一些元数据来注释关注的<Camera-11>资源。特别地，<semanticDescriptor>子资源存储两个RDF三元组(作为现有事实)：

·RDF三元组#1(例如，事实-a)：相机-11是ontologyA:VideoCamera(其中“VideoCamera”是由本体A定义的类)。

·RFC三元组#2(例如，事实-b)：相机-11位于建筑物-1的房间-109中。

示例1：考虑用户需要从所有房间检索实时图像。为此，用户首先需要首先执行语义资源发现，以使用以下SPARQL语句-I来识别相机：

实际上，<Camera-11>的语义注释和SPARQL语句-I很有可能可以使用不同的本体，因为它们可以由不同方提供。例如，对于<Camera-11>的语义注释，事实-a中使用的本体类“VideoCamera”来自本体A。相比之下，SPARQL语句-I中使用的本体类“VideoRecorder”来自另一个不同的本体B。由于缺少语义推理能力，因此系统无法断定ontologyA:VideoCamera确实与ontologyB:VideoRecorder相同。因此，在语义资源发现处理期间，<Camera-11>资源无法被识别为期望资源，因为SPARQL处理基于精确的模式匹配(但是在这个示例中，事实-a无法匹配SPARQL语句-I中的模式“？device is-a ontologyB:VideoRecorder”)。

示例2：在这个示例中说明了更复杂的情况，其中用户仅想从“属于特定管理区(例 如，MZ-1)”的房间中检索实时图像。于是，用户可以首先使用以下SPARQL语句-II来执行语义资源发现：

在示例-2(与示例-1类似)中，由于缺少语义推理支持，<Camera-11>资源无法被识别为期望的资源(此时，事实-a与SPARQL语句-II中的模式“？device is-a ontologyA:VideoCamera”匹配，但是事实-b不能匹配模式“？device monitors-room-in MZ-1”)。

示例2还说明了由于缺乏足够的事实输入来进行推理处理引起的关键语义推理问题。例如，即使假设启用了语义推理并且可以利用以下推理规则(例如，RR-1)：

·RR-1：IF X位于Y中&&Y在Z的管理之下，THEN X监视Z中的房间

通过语义推理处理通过对事实-Y应用RR-1仍无法得出推断事实。原因是事实-b可以仅匹配RR-1中的“X位于Y中”部分(例如，用<Camera-11>替换X并且用“建筑物-1中的房间-109”替换Y)。但是，除了事实-a和事实-b之外，没有另外的事实可以被用来匹配RR-1中的“Y在Z的管理之下”部分(例如，没有足够的事实来使用RR-1)。事实上，这里缺少的事实是关于医院房间分配。医院房间分配记录可以是定义哪些房间属于哪个MZ的RDF三元组的集合，例如，以下RDF三元组描述了建筑物-1的房间-109属于MZ-1：

·事实-c：建筑物-1的房间-109在MZ-1的管理之下

·…..

在没有事实-c的情况下，由于缺乏足够的事实作为推理处理的输入，因此语义推理在这个示例中仍然无济于事。

通过充分利用特征-2，SRF现在可以解决示例-1中所示的问题。例如，推理规则(RR-2)可以被定义为：

·RR-2：IF X是ontologyA:VideoCamera的实例，THEN X也是ontologyB:VideoRecorder的实例。

在此，X是变量，并且在推理处理期间将由特定实例(例如，示例-1中的<Camera-11>)替换。当SPARQL引擎正在处理SPARQL语句-I时，它还可以在语义推理器(SR)处触发语义推理处理，该处理将把RR-2(作为RS)应用于事实-a(作为inputFS)。可以产生inferredFS，其包括以下新事实：

·推断事实-a：相机-11是ontologyB:VideoRecorder

SPARQL引擎现在能够使用推断事实-a来匹配SPARQL语句-I中的模式“？deviceis-a ontologyB:VideoRecorder”。因此，利用SRF的帮助，现在可以在语义资源发现期间将<Camera-11>资源识别为期望资源。

SRF的特征-2也可以解决示例-2中所示的问题。例如，当SPARQL引擎处理SPARQL语句-II时，它还可以在SR处触发语义推理处理。特别地，SR确定应当利用RR-1(作为RS)。同时，可以将SR的本地策略配置为：为了成功应用RR-1，现有的事实-b是不够的，并且附加的事实-c也应当用作推理处理的输入(例如，事实-c是定义建筑物-1的房间-109属于MZ-1的医院房间分配记录)。在这种情况下，inputFS被进一步分类为两部分：initial_InputFS(例如，事实-b)和additional_InputFS(例如，事实-c)。因此，通过将RR-1应用于“组合的inputFS”(例如，事实-b和事实-c)，可以产生inferredFS，其包括以下新事实：

·推断事实-b：相机-11监视MZ-1中的房间

现在，SPARQL引擎能够进一步使用推断事实-c来匹配SPARQL语句-II中的查询模式“？device monitors-room-in-MZ-1”。因此，现在可以在示例-2中的语义资源发现操作中成功识别<Camera-11>。

总的来说，特征-2的一般流程是oneM2M用户(作为发起方)可以将请求发送到某些接收方CSE，以进行期望的语义操作(诸如语义资源发现、语义查询等)。在请求处理期间，接收方CSE还可以充分利用推理能力。通过使用推理结果，接收方CSE将进一步产生发起方所请求的语义操作的最终结果(例如，语义查询结果或语义发现结果)，然后将响应发送回发起方。

特征-3：以下公开启用个体语义推理处理：除了特征-2所支持的用例之外，语义推理处理还可以由oneM2M用户单独触发(在图35中由箭头383示出)。换句话说，语义推理处理不一定与特征-2中考虑的其它语义操作耦合。利用特征-3，oneM2M用户可以通过触发语义推理处理直接与SRF交互。为此，oneM2M用户应首先基于其应用需求来识别感兴趣的事实(作为initial_inputFS)以及期望的推理规则(作为RS)。当识别出inputFS和RS时，oneM2M用户应通过指定推理输入(例如，识别出的initial_inputFS和RS)向SR发送请求，以触发特定的语义推理处理。SR可以基于用户所指示的输入来发起语义推理处理。与特征-2相似，如果来自用户的输入不足，那么SR还可以确定需要充分利用哪些附加FS或RS。一旦SR计算出语义推理结果，它就将根据需要被返回给oneM2M用户。通常，特征-3可以支持以下情况。

在第一种情况(情况-1)中，oneM2M用户可以使用SRF对低级数据进行语义推理，以便获得高级知识。例如，公司向客户出售健康监视产品并且这个产品事实上充分利用语义推理能力。在这个产品中，其中一款是健康监视app(充当oneM2M用户)。这个app可以请求SRF通过使用心脏病发作诊断/预测推理规则来对从特定患者A收集的实时生命数据(诸如血压、心跳等)执行语义推理处理。在这个处理中，心脏病发作诊断/预测推理规则是用户定义的规则，其可以基于患者A自己的健康简档和他/她过去的心脏病发作历史进行高度定制。以这种方式，健康监视应用不必处理低级生命数据(例如，血压、心跳等)，并且可以避免确定患者A的心脏病发作风险(因为所有诊断/预测业务逻辑已经在由SRF使用的推理规则中定义)。因此，健康监视app仅需要利用推理结果(例如，患者A当前的心脏病发作风险，其为“即用型或高级”知识)并且如有需要就将警报发送给医生或拨打911以请求救护车。

在第二种情况(情况-2)中，oneM2M用户可以使用SRF进行语义推理以丰富现有数据。仍然以示例-1为例，oneM2M用户(例如，相机-11的所有者)可以通过使用特征-3和RR-2来对<Camera-11>的语义注释(例如，事实-a和事实-b作为现有事实)主动触发语义推理处理。语义推理结果(例如，推断事实-a)也是关于<Camera-11>的低级语义元数据，并且是长期有效的事实；因此，可以将这种新的/推断事实进一步添加/集成到<Camera-11>的语义注释中。换句话说，现有事实现在被推断事实“丰富或扩充”。因此，<Camera-11>可以通过未来的语义资源发现操作获得更多被发现的机会。这种丰富的另一个优点是，未来的语义资源发现操作不必像特征-2支持的那样每次都在后台进一步触发语义推理，这有助于减少处理开销和响应延迟。但是，值得注意的是，它可能不适用于在所有用例中将推断事实与现有事实集成。以示例-2为例，推断事实-b(例如，“相机-11监视MZ-1中的房间”)是相对高级的知识，其可能不适于与低级语义元数据(例如，事实-a和事实-b)集成。同时，由于可能会不时重新安排医院房间分配，因此推断事实-b可以只是短期有效的事实。例如，在最近的房间重新分配之后，虽然相机-11仍位于建筑物-1的房间-109中(例如，事实-a和事实-b仍然有效)，但这个房间现在用于其它用途，于是属于不同的MZ(例如，推断事实-b不再有效，并且需要被删除)，因此相机-11不再监视属于MZ-1的房间。因此，将这种类型的推断事实或知识直接集成到大型相机的语义注释中是没有意义的，反而可能会导致相当大的注释更新开销。可以看出，特征-2和特征-3都是SRF的必要特征，并且它们中的每一个都分别支持不同的用例。

总体而言，特征-3的一般流程是oneM2M用户(作为发起方)可以将请求发送到具有推理能力的某些接收方CSE。因而，接收方CSE将通过使用期望的输入(例如，inputFS和RS)来进行推理处理，并产生推理结果，最后将响应发送回发起方。

本文公开了与本公开相关联的附加考虑。许多概念、术语、名称可以具有等效的名称。因此，以下表45中是示例性列表。

表45

图37A是示例机器到机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图，其中可以实现与启用语义推理支持操作相关联的一个或多个公开的概念(例如，图7-图15和随附的讨论)。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关或M2M服务平台都可以是IoT/WoT以及IoT/WoT服务层等的部件。

如图37A中所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。另外，例如，通信网络12可以包括其它网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或企业网络。

如图37A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域。基础设施域是指端到端M2M部署的网络侧，并且场域是指通常在M2M网关后面的区域网络。场域包括M2M网关14和终端设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M终端设备18可以包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M终端设备18中的每一个被配置为经由通信网络12或直接无线电链路发送和接收信号。M2M网关设备14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)或者通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M设备18可以经由通信网络12或直接无线电链路从M2M应用20或M2M设备18收集数据并向M2M应用20或M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20接收，如下所述。M2M设备18和网关14可以经由各种网络进行通信，包括例如蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。

参考图37B，所示的场域中的M2M服务层22为M2M应用20、M2M网关设备14和M2M终端设备18以及通信网络12提供服务。将理解的是，M2M服务层22可以根据期望与任何数量的M2M应用、M2M网关设备14、M2M终端设备18和通信网络12通信。M2M服务层22可以由一个或多个服务器、计算机等实现。M2M服务层22提供应用于M2M终端设备18、M2M网关设备14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如作为web服务器、在蜂窝核心网络中、在云中等等。

类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12'提供服务。M2M服务层22'还为场域中的M2M网关设备14和M2M终端设备18提供服务。将理解的是，M2M服务层22'可以与任何数量的M2M应用、M2M网关设备和M2M终端设备通信。M2M服务层22'可以与不同服务提供者的服务层交互。M2M服务层22'可以由一个或多个服务器、计算机、虚拟机(例如，云/计算机/存储场等)等实现。

还参考图37B，M2M服务层22和22'提供不同应用和行业(verticals)可以充分利用的核心服务递送能力集。这些服务功能使M2M应用20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等的功能。基本上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过各种网络12和12'与服务层22和22'提供的服务相连接地进行通信。

在一些示例中，如本文所公开的，M2M应用20和20'可以包括使用语义推理支持操作进行通信的期望应用。M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全性和监控。如上面所提到的，在系统的设备、网关和其它服务器之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及遗留系统集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。

可以将本申请的语义推理支持操作实现为服务层的一部分。服务层是中间件层，其通过应用编程接口(API)和底层网络接口的集合支持增值服务能力。M2M实体(例如，诸如设备、网关或在硬件上实现的服务/平台之类的M2M功能实体)可以提供应用或服务。ETSIM2M和oneM2M都使用服务层，该服务层可以包括本申请的语义推理支持操作。oneM2M服务层支持公共服务功能(CSF)(例如，服务能力)的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上托管。另外，本申请的语义推理支持操作可以被实现为M2M网络的一部分，该M2M网络使用面向服务的体系架构(SOA)或面向资源的体系架构(ROA)来访问诸如本申请的语义推理支持操作之类的服务。

如本文所公开的，服务层可以是网络服务体系架构内的功能层。服务层通常位于应用协议层(诸如HTTP、CoAP或MQTT)之上，并为客户端应用提供增值服务。服务层还提供到在较低资源层(诸如例如控制层和运输/接入层)处的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层，以解决与M2M类型的设备和应用集成到诸如互联网/Web、蜂窝、企业和家庭网络之类的部署中相关联的挑战。M2M服务层可以为应用或各种设备提供对由服务层支持的上面提到的能力或功能集合的访问，服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、收费、数据管理、设备管理、发现、供应以及连接性管理，这些可以被各种应用共同使用。经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API使这些能力或功能对这些各种应用可用。CSE或SCL是可以由硬件或软件实现的功能实体，并且提供暴露于各种应用或设备的(服务)能力或功能(例如，这些功能实体之间的功能接口)，以便它们使用这样的能力或功能。

图37C是示例M2M设备30的系统图，例如诸如M2M终端设备18(其可以包括AE 331)或M2M网关设备14(其可以包括图13至图15的一个或多个部件)。如图37C中所示，M2M设备30可以包括处理器32、收发器34、传输/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50以及其它外围设备52。将认识到的是，M2M设备30可以包括前述元件的任何子组合，同时与所公开的主题保持一致。M2M设备30(例如，CSE 332、AE331、CSE 333、CSE 334、CSE 335等)可以是执行所公开的用于语义推理支持操作的系统和方法的示例性实施方式。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理，或使M2M设备30能够在无线环境中操作的任何其它功能。处理器32可以与收发器34耦合，收发器34可以与传输/接收元件36耦合。虽然图37C将处理器32和收发器34描绘为分开的部件，但是将认识到的是，处理器32和收发器34可以在电子包装或芯片中集成在一起。处理器32可以执行应用层程序(例如，浏览器)或无线电接入层(RAN)程序或通信。例如，处理器32可以例如诸如在接入层或应用层处执行安全性操作，诸如认证、安全密钥协商或加密操作。

传输/接收元件36可以被配置为向M2M服务平台22传输信号或从M2M服务平台22接收信号。例如，传输/接收元件36可以是被配置为传输或接收RF信号的天线。传输/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在示例中，传输/接收元件36可以是被配置为例如传输或接收IR、UV或可见光信号的发射器/检测器。在又一个示例中，传输/接收元件36可以被配置为传输和接收RF和光信号两者。将认识到的是，传输/接收元件36可以被配置为传输或接收无线或有线信号的任意组合。

此外，虽然传输/接收元件36在图37C中被描绘为单个元件，但是M2M设备30可以包括任何数量的传输/接收元件36。更具体而言，M2M设备30可以采用MIMO技术。因此，在示例中，M2M设备30可以包括用于传输和接收无线信号的两个或更多个传输/接收元件36(例如，多个天线)。

收发器34可以被配置为调制将由传输/接收元件36传输的信号并且解调由传输/接收元件36接收的信号。如上所述，M2M设备30可以具有多模式能力。因此，例如，收发器34可以包括多个收发器，用于使M2M设备30能够经由多个RAT(诸如UTRA和IEEE802.11)进行通信。

处理器32可以从任何类型的合适存储器(诸如不可移动存储器44或可移动存储器46)访问信息，并将数据存储在其中。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘，或任何其它类型的存储器存储设备。可移动存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它示例中，处理器32可以从物理地位于M2M设备30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为响应于本文描述的一些示例中的语义推理支持操作是成功还是失败(例如，获得语义推理资源等)来控制显示器或指示器42上的照明图案、图像或颜色，或以其它方式指示语义推理支持操作和相关联部件的状态。控制显示器或指示器42上的照明图案、图像或颜色可以反映本文说明或讨论的附图(例如，图6-图36等)中的任何方法流程或部件的状态。本文公开了语义推理支持操作的消息和过程。消息和过程可以被扩展以提供接口/API，以供用户经由输入源(例如，扬声器/麦克风38、小键盘40或显示器/触摸板42)请求与服务层相关的信息。在附加的示例中，除了可以显示在显示器42上的内容之外，尤其还可以存在语义推理支持的请求、配置或查询。

处理器32可以从电源48接收电力，并且可以被配置为向M2M设备30中的其它部件分配或控制电力。电源48可以是用于为M2M设备30供电的任何合适的设备。例如，电源48可以包括一个或多个干电池(例如，镍-镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。

处理器32还可以与GPS芯片组50耦合，GPS芯片组50被配置为提供关于M2M设备30的当前位置的位置信息(例如，经度和纬度)。将认识到的是，M2M设备30可以通过任何合适的位置确定方法获取位置信息，同时与本文公开的信息保持一致。

处理器32还可以与其它外围设备52耦合，外围设备52可以包括提供附加特征、功能或者有线或无线连接性的一个或多个软件或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物测定(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等等。

传输/接收元件36可以在其它装置或设备中实施，诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子健康设备、机器人、工业装备、无人机、车辆(诸如小汽车、卡车、火车或飞机)。传输/接收元件36可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。

图37D是示例性计算系统90的框图，例如，可以在其上实现图37A和图37B的M2M服务平台22。计算系统90(例如，M2M终端设备18或M2M网关设备14)可以包括计算机或服务器，并且可以主要由计算机可读指令通过存储或访问这些指令的任何手段来控制。这种计算机可读指令可以在中央处理单元(CPU)91内执行，以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91或协处理器81可以接收、生成和处理与所公开的用于语义推理支持操作(诸如获得语义推理资源)的系统和方法相关的数据。

在操作中，CPU 91取出、解码并执行指令，并经由计算机的主数据传输路径(系统总线80)向其它资源传送信息和传送来自其它资源的信息。这种系统总线连接计算系统90中的部件并定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线，以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围部件互连)总线。

与系统总线80耦合的存储器设备包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路系统。ROM 93一般包括不能被容易地修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其它硬件设备读取或改变。对RAM82或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，该地址翻译功能在执行指令时将虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，该存储器保护功能隔离系统内的进程并将系统进程与用户进程隔离。因此，以第一模式运行的程序只能访问由其自己的进程虚拟地址空间映射的存储器；除非已设置进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。

此外，计算系统90可以包括外围设备控制器83，其负责将来自CPU 91的指令传递到外围设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85。

由显示器控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示器控制器96包括生成发送到显示器86的视频信号所需的电子部件。

另外，计算系统90可以包括网络适配器97，其可以用于将计算系统90连接到外部通信网络，诸如图37A和图37B的网络12。

应该理解的是，本文描述的任何或所有系统、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，当指令由机器(诸如计算机、服务器、M2M终端设备、M2M网关设备等)执行时，执行或实现本文描述的系统、方法和处理。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质，但是这种计算机可读存储介质本身不包括信号。如从本文的描述中可以明显看出的，存储介质应当被解释为法定主题。计算机可读存储介质包括RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字通用盘(DVD)或其它光盘存储器、磁带盒、磁带、磁盘存储装置或其它磁存储设备，或者可以用于存储期望信息并可以由计算机访问的任何其它物理介质。计算机可读存储介质其上可以存储有计算机程序，该计算机程序可以可加载到数据处理单元中，并且适于在由数据处理单元运行计算机程序的语义推理支持操作时使数据处理单元执行方法步骤。

在描述本公开的主题(启用语义推理支持操作)的优选方法、系统或装置中，如图所示，为了清楚起见，采用特定术语。但是，所要求保护的主题并不旨在限于如此选择的特定术语，并且应当理解的是，每个特定元件包括以类似方式操作以实现类似目的的所有技术等同物。

本文描述的各种技术可以结合硬件、固件、软件或者(在适当的情况下)其组合来实现。这种硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置中。装置可以单独操作或彼此组合操作，以实现本文所描述的方法。如本文所使用的，术语“装置”、“网络装置”、“节点”、“设备”、“网络节点”等可以互换使用。此外，除非本文另外提供，否则词“或”的使用一般被包含性地使用。

本书面描述使用示例来公开主题，包括最佳模式，并且还使本领域技术人员能够实践要求保护的主题，包括制造和使用任何设备或系统以及执行任何结合的方法。本主题的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例(例如，在本文公开的示例性方法之间跳过步骤、组合步骤或添加步骤)。例如，可以跳过步骤344。在另一个示例中，可以跳过或添加步骤204和步骤205。如果这些其它示例具有与权利要求的字面语言没有不同的结构元件，或者如果它们包括与权利要求的字面语言无实质差别的等效结构元件，那么这些其它示例旨在权利要求的范围内。

如本文所述的方法、系统和装置尤其可以提供用于在推理支持下提供或管理服务层语义的手段。方法、系统、计算机可读存储介质或装置具有用于获得消息的手段，该消息包括语义推理请求以及关于第一事实集的信息和关于第一规则集的信息；基于消息，检索第一事实集和第一规则集；基于第一事实集和第一规则集来推断推断事实；以及提供将推断事实集存储在装置上以用于后续语义操作的指令。关于第一事实集的信息可以包括第一事实集的统一资源标识符。关于第一事实集的信息可以包括与第一事实集相关联的本体。可以进一步基于关于匹配与第一规则集相关联的本体的第一事实集的信息来确定是否使用第二事实集或第二规则集。还可以基于关于与装置的配置表中的关键词匹配的第一事实集的信息来确定是否使用第二事实集或第二规则集。操作还可以包括基于第一事实集和第一规则集来推断推断事实。后续语义操作可以包括语义资源发现。后续语义操作可以包括语义查询。装置可以是语义推理器(例如，公共服务实体)。这个段落中的所有组合(包括步骤的去除或添加)以与具体实施方式的其它部分一致的方式被预期。

Claims (15)

1.一种用于在服务层中进行语义推理的装置，所述装置包括：

处理器；以及

存储器，与处理器耦合，所述存储器包括存储在其上的可执行指令，所述可执行指令在由处理器执行时使处理器实现包括以下的操作：

获得消息，所述消息包括语义推理请求以及关于第一事实集的信息和关于第一规则集的信息；

基于消息，检索第一事实集和第一规则集；

基于第一事实集和第一规则集来推断推断事实；以及

提供将推断事实集存储在装置上以用于后续语义操作的指令。

2.如权利要求1所述的装置，其中关于第一事实集的信息包括第一事实集的统一资源标识符。

3.如权利要求1所述的装置，其中关于第一事实集的信息包括与第一事实集相关联的本体。

4.如权利要求1所述的装置，所述操作还包括基于检索到的第一事实集和第一规则集来确定是否使用第二事实集或第二规则集。

5.如权利要求1所述的装置，所述操作还包括基于关于与第一规则集相关联的本体匹配的第一事实集的信息来确定是否使用第二事实集或第二规则集。

6.如权利要求1所述的装置，所述操作还包括基于关于与装置的配置表中的关键词匹配的第一事实集的信息来确定是否使用第二事实集或第二规则集。

7.如权利要求1所述的装置，其中后续语义操作包括语义资源发现。

8.如权利要求1所述的装置，其中后续语义操作包括语义查询。

9.如权利要求1所述的装置，其中所述装置是语义推理器。

10.一种用于服务层中的语义推理的方法，所述方法包括：

由公共服务实体获得消息，所述消息包括语义推理请求以及关于第一事实集的信息和关于第一规则集的信息；

基于所述消息，检索第一事实集和第一规则集；

基于第一事实集和第一规则集来推断推断事实；以及

提供将推断事实集存储在公共服务实体上以用于后续语义操作的指令。

11.如权利要求10所述的方法，其中关于第一事实集的信息包括与第一事实集相关联的本体。

12.如权利要求10所述的方法，还包括基于检索到的第一事实集和第一规则集来确定是否使用第二事实集或第二规则集。

13.如权利要求10所述的方法，还包括基于关于与第一规则集相关联的本体匹配的第一事实集的信息来确定是否使用第二事实集或第二规则集。

14.如权利要求10所述的方法，还包括基于关于与公共服务实体的配置表中的关键词匹配的第一事实集的信息来确定是否使用第二事实集或第二规则集。

15.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序能够被加载到数据处理单元中并适于在计算机程序被数据处理单元运行时使数据处理单元执行如权利要求11至14中的任一项所述的方法步骤。

Images