机器到机器(m2m)通信是实体之间的一种数据通信形式，所述实体当被部署时不一定需要直接人类交互。m2m通信的一个挑战是建立协议使得可以高效地管理所部署的设备。m2m技术已在诸如以下各项的不同领域中实现各种应用：系统状态监控；自动电能计量、家庭自动化、智能建筑中的无线监控、个人区域网络、参数的监控、定位以及医疗技术中的实时位置等。语义网(semanticweb)语义网(semanticweb)是由万维网联盟(w3c)通过标准对web的扩展。标准促进web上的公用数据格式和交换协议，最根本上是资源描述框架(rdf)。语义网涉及用专门为数据设计的语言：资源描述框架(rdf)、web本体语言(owl)和可扩展标记语言(xml)发布。这些技术被组合以提供经由链接数据的web补充或者替换web文档的内容的描述。因此，内容可以本身表示存储在web可访问数据库中的描述性数据，或者表示在文档内特别是在散布着xml的可扩展html(xhtml)中或者更经常纯粹地在xml中的标记，其中布局或渲染线索被单独地存储。语义网栈语义网栈图示由w3c指定的语义网的架构，如图1中所示。可将组件的功能和关系概括如下。xml为文档内的内容结构提供元素语法，然而未使语义与包含在内部的内容的含义相关联。在大多数情况下，xml目前不是语义网技术的必要组件，因为存在替代语法，例如turtle。turtle是事实上标准，但是尚未通过正式标准化进程。xml模式是用于提供并限制包含在xml文档内的元素的结构和内容的语言。rdf，用于在web中表示信息的框架。rdf本质上是数据模型。其基本构件是主语-谓语-宾语三元组，被称作语句。主语定义语句所关于的资源。谓语(或关系)定义主语与宾语之间的关系。宾语定义作为语句的宾语的资源或值。在图2中所示的示例中，能用turtle语法(rdf1.1turtle，http://www.w3.org/tr/turtle/#language-features)将rdf语句编写如下，这意味着johnsmith(约翰史密斯)的头衔是教授。使用rdf模型的所有信息是以rdf语句的格式(即，rdf三元组)表示的。：johnsmith(主语)：具有头衔(谓语/关系)：教授(宾语)rdf模式(rdfs)扩展rdf并且是用于描述基于rdf的资源的性质和类的词汇，具有用于此类性质和类的通用层次的语义。与rdfs对比，owl添加用于描述性质和类的更多词汇以改进表达性：其中，类之间的关系(例如不相交)、基数(例如“恰好一个”)、相等、性质的更丰富类型、性质的特性(例如对称性)和枚举类。sparql是用于语义网数据源的协议和查询语言，以在web上或在rdf暂存器(即语义图暂存器)中查询并操纵rdf图形内容(即rdf三元组)。sparql1.1query(用于rdf图的查询语言)可用于表达跨越各种数据源的查询，而无论数据被在本地存储为rdf还是经由中间件视为rdf。sparql包含用于查询需要的且可选的图形模式及其合取和析取的能力。sparql还支持聚合、子查询、否定、通过表达式创建值、可扩展值测试以及通过源rdf图约束查询。sparql查询的结果可以是结果集或rdf图。sparql1.1update是用于rdf图的更新语言。它使用从用于rdf的sparql查询语言导出的语法。对语义图暂存器中的图的合集执行更新操作。操作被提供来在语义图暂存器中更新、创建并移除rdf图。rif是w3c规则交换格式。它是用于表达计算机可执行的web规则的xml语言。rif提供多个版本，被称作方言(dialect)。它包括rif基本逻辑方言(rif-bld)和rif产生式规则方言(rifprd)。rdfs和owl推理rdfs通过定义可在rdf文档中使用的一些更多的词汇(例如，subclassof、subpropertyof)来扩展rdf。这意味着我们可利用一些rdfs结构来导出新信息。表1列举在rdf三元组中基于rdfs词汇定义逻辑的rdfs推理规则的一些示例。表1：rdfs推理规则(rdfs推断)的示例在表中呈现了rdf三元组的一般格式。例如，usy是rdf三元组，其中主语u、谓语s和宾语y可能是任何类、关系或文字。取编号3rdfs规则作为实例，在本体中，c能被定义为狗类，c1能被定义为哺乳动物类，并且c2能被定义为动物类。如果类狗被定义为类哺乳动物的子类，并将类哺乳动物被定义为类动物的子类，则可推断狗是动物的子类。能用turtle语法在rdf三元组中编写此示例如下：如早先提及的，利用rdf模式(rdfs)能够仅定义类和性质的层次之间的关系，或者定义这些性质的域和范围。owl是为具有更丰富词汇的更复杂本体而定义的，并且它使得能实现比rdfs更复杂的推理。表2列举基于owl词汇定义逻辑的owl推理规则的一些示例。第二列指定条件(事实)，并且第三列指示在第二列中的所有事实都发生情况下的结论。例如作为编号3规则，如果v被定义为一般owl:class，并且类v等于类w，则能断定类v是类w的子类。表2：owl推理规则(owl推理)的示例推理规则语言语义网规则语言(swrl)是提议的用于语义网的语言，其可用于表达规则以及逻辑，将owldl或owllite与规则标记语言的子集组合。swrl由w3c标准化。规则交换格式(rif)是w3c推荐标准。rif是用于语义网以及(主要)sparql、rdf和owl的基础设施的一部分。尽管最初被许多人想象为用于语义网的“规则层”，然而实际上rif的设计基于存在许多“规则语言”的观察结果，并且所需的是在它们之间交换规则。rif包括三个方言(dialect)，即被扩展成基本逻辑方言(bld)和产生式规则方言(prd)的核心方言。onem2m架构在开发中的onem2m标准(onem2m-ts-0001onem2mfunctionalarchitecture-v2.5.0)定义被称作“公共服务实体(cse)”的服务层。服务层的目的是为了提供可被不同的“垂直”m2m系统和应用利用的“水平”服务。如图3中所示，cse支持四个参考点。mca参考点与应用实体(ae)对接。mcc参考点与相同的服务提供商域内的另一cse对接并且mcc’参考点与不同的服务提供商域中的另一cse对接。mcn参考点与底层网络服务实体(nse)对接。nse向cse提供底层网络服务，诸如设备管理、位置服务和设备触发。cse包含被称作“公共服务功能(csf)”的多个逻辑功能，诸如“发现”、“数据管理和储存库”。图4图示onem2m处的开发中的csf。m2m语义支持的功能架构图5示出提议的用于m2m语义支持的功能/逻辑架构。主要组件可以包括数据储存库201、本体储存库202、本体建模和处理203、语义储存库204或推理200等。数据储存库201基本上包括新数据。此外，它还提供用于支持所存储的数据的搜索、修改和删除的功能。本体储存库202包括本体。本体是将概念定义为宾语的概念化的正式规范，其中其性质和关系与其它概念相对。因此，可将本体论定义为语言工件，所述语言工件定义关于一件实体(主题域)的公开内容的基本概念的共享词汇并且指定包括操作的那些概念。本体建模和处理203—本体建模是用于构建本体的进程，所述本体用于对域进行建模并支持关于概念的推理。用于本体建模的语言的示例是基于xml的rdf、rdf模式(rdfs)、owl等。本体处理是对m2m域的外部和内部发布/建模的本体进行分类、存储并且提供其发现功能的进程。本体被用统一语言(例如，rdfs/owl)转换并存储在本体储存库中，所述统一语言可被共享并用于使得能实现资源的语义。语义储存库204包括某些表示中的注释语义信息，所述某些表示可以具有利用rdf的选项。语义注释是以具体格式(诸如二进制流)表示资源的语义的进程。m2m资源的语义注释是用于向m2m资源添加语义信息使得它向异构m2m应用提供一致数据转换和数据互操作性的方法。在语义储存库中维护的语义上注释的m2m资源可由理解什么数据通过资源来提供并且这些数据意指什么的m2m应用来联系。仅仅与传统m2m系统相比，这些注释提供更有意义的描述并且暴露m2m数据。推理200是用于从语义上注释的数据导出新隐式知识并且回答复杂用户查询的机制。它可作为要能够从一组断言的事实或公理推断逻辑结果的一件软件被实现。语义分析和查询206—在语义分析和查询中，在语义上分析来自m2m应用的请求。基于分析，它创建语义查询消息并且将消息发送到用于请求语义信息的抽象和语义中的功能组件(例如，本体储存库、推理、语义混搭等)。在获得所请求的信息之后，它对m2m应用进行响应。onem2m架构中的语义描述<semanticdescriptor>资源用于存储与资源和可能其它语义上相关的资源有关的语义描述。这种描述是根据本体提供的。语义信息由onem2m系统的语义功能性使用并且也被应用或cse利用。当前<semanticdescriptor>资源可能是在<ae>、<container>、<contentinstance>、<group>和<node>资源下的子资源。<semanticdescriptor>资源包含表3中指定的属性(而不用列举在onem2m-ts-0001onem2mfunctionalarchitecture-v2.5.0中定义的公共和通用属性)。表3：<semanticdescriptor>资源的属性onem2m中的语义过滤提议通用过滤是通过具有在请求操作(onem2m-ts-0001onem2mfunctionalarchitecture-v2.5.0-第8.1.2节)中指定的过滤准则来支持的。为了提供语义过滤，已在onem2mtr-0007-study_on_abstraction_and_semantics_enablement-v2.6.0-第8.5.4节中提议用于请求操作过滤准则的附加值，其中定义被示出在下表中。可以使用多个实例，在此情况下逻辑“或”在实例之间适用，即如果语义过滤器中的一个或多个与语义描述匹配则用于语义过滤准则的整体结果是真。表4.过滤准则中的“语义”属性以上提议使用以下假设：语义描述被指定为rdf三元组(仍然尚未在onem2m中完全指定表示，例如rdf/xml、turtle、描述格式)；语义过滤准则将被用于要对语义描述执行的sparql请求。onem2m中的基础本体和本体映射当前，onem2m正在定义基础本体。基础本体是onem2m将标准化的唯一本体，并且是使得其它本体可被映射到onem2m所需要的最小本体(即，强制最少数目的约定)。基础本体的主要目的是为了增强互操作性。任何外部本体能被发布到onem2m服务层，并且被映射到基础本体。出版商的责任是做外部本体与基础本体之间的映射。在onem2mts-0012-baseontology-v0.6.0中定义了一些映射原理。本体是相对静态的，即，一旦它被定义并发布到m2m系统它就很少发生改变。应用能通过本体发现进程来知道本体。onem2m语义框架中的语义推理在onem2mtr-0007-study_on_abstraction_and_semantics_enablement-v2.6.0中，语义推理被定义为用于从语义注释的数据导出新隐式知识并且回答复杂用户查询的机制。它可作为要能够从一组断言的事实或公理推断逻辑结果的一件软件被实现。此外，标识了用于在onem2m语义框架内实现语义推理的一些要求。表5：针对语义推理的要求定义。蕴涵：推论或暗示，即，在逻辑上遵循或者通过别的东西暗示的东西。语义推理：用于从语义上注释的数据导出新隐式知识并且回答复杂用户查询的机制。它可作为要能够从一组断言的事实或公理推断逻辑结果的一件软件被实现。语义推理规则定义能用于基于现有信息导出一些新知识的某个逻辑。语义规则集中于在使用逻辑方式来基于本体中的现有概念和关系生成新关系时定义一般机制。语义注释：用于将语义信息(即，元数据、rdf三元组)添加到原始信息(例如，onem2m中的m2m资源)以用于向异构m2m应用提供一致数据转换和数据互操作性的方法。本体论：将概念定义为宾语的概念化(词汇)的正式规范，其中其性质和关系与其它概念相对。本体集中于分类方法，强调定义“类”、“子类”、个别资源如何可与这些类相关联以及表征类及其实例之间的关系。本体储存库：本体的存储数据库。语义图暂存器：存储语义信息的数据库。具体地，如果使用rdf数据模型，则它是存储rdf三元组的triplestore。技术实现要素：语义推理提供基于依靠所定义的推理规则的现有信息来提取新信息并且因此使得实现不同域(例如，智能家庭、智能交通和环境监控)之间的互操作性的能力。然而，尚未定义如何在m2m/iot服务层处实现语义推理能力。本公开定义用于在m2m/iot系统中的语义框架内实现语义推理服务的机制。公开了以下内容：1)语义推理处理器的整体架构，其突出推理进程的功能组件和流程；2)针对不同场景定义的用于m2m/iot系统中的推理规则管理的过程(例如，创建和删除)；3)用于在m2m/iot系统中触发并执行语义推理进程的过程，其可以通过语义查询和语义注释进程以按需且积极方式触发；以及4)处置并处理通过语义推理进程所生成的新信息的方法，其可以包括生成更多的语义信息来描述所生成的信息(例如，新数据内容)。另外本文中公开的是示出如何将相关联的语义推理应用于onem2m面向资源架构(roa)的新资源、属性和消息格式。本
发明内容被提供来以简化形式引入将在下面在具体实施方式中进一步描述的一些概念。本
发明内容不旨在标识所要求保护的主题的关键特征或必要特征，它也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不局于解决在本公开的任何部分中指出的任何或所有缺点的局限。附图说明可以从结合附图作为示例给出的以下描述中获得更详细的理解，其中：图1图示语义网的架构；图2图示rdf图的示例；图3图示onem2m架构；图4图示onem2m公共服务功能；图5图示m2m语义支持的功能架构；图6图示<semanticdescriptor>资源的结构；图7图示用于在m2m服务层语义框架内实现语义推理的示例性方法；图8a图示用于智能建筑的示例性本体；图8b图示图8a的示例性灯域本体；图9图示灯域的示例性本体；图10图示用于在m2m服务层语义框架内实现语义推理的示例性方法；图11图示示例性本体；图12图示用于方便语义查询的指令的示例；图13图示m2m系统中的语义推理的示例性功能架构；图14图示用于规则管理和语义推理进程的示例性方法；图15图示用于在新本体被发布并存储在m2m系统中时创建类型2推理规则的示例性方法；图16图示在本体被更新时创建类型2推理规则的示例性方法；图17图示用于在本体被更新时删除推理规则的示例性方法；图18图示通过语义查询进程触发的语义推理进程的示例性方法；图19图示通过语义注释进程触发的语义推理进程的示例性方法；图20图示用于处理经由推理进程生成的新信息的示例性方法；图21图示具有语义推理的示例性onem2mcse；图22图示与作为服务的语义推理相关联的示例性用户接口；图23图示可以像本文中所讨论的那样基于实现语义推理服务的方法和系统而生成的示例性显示(例如，图形用户接口)；图24a是可以实现所公开的主题的示例机器到机器(m2m)或物联网(iot)通信系统的系统图；图24b是可以在图24a中所图示的m2m/iot通信系统内使用的示例架构的系统图；图24c是可以在图24a中所图示的通信系统内使用的示例m2m/iot终端或网关设备的系统图；以及图24d是可以具体实现图24a的通信系统的各方面的示例计算系统的框图。具体实施方式本文中公开的是用于在m2m/iot系统中的语义框架内实现语义推理服务的机制。在下面讨论的是提供关于所公开的语义推理服务的附加观点的场景。参考第一场景，图7图示描述由定义图9的本体101的灯控制应用106所发起的语义查询的进程的流程。如在下面更详细地讨论的，如果未触发或者实现推理能力，则具有本体101的灯控制应用106可以不接收关于由图8b的本体100所定义的灯103的准确信息。本文中公开的是如何且何时触发推理并执行推理进程的方法，所述推理进程在常规机器到机器(m2m)系统中未定义。通过推理进程使用的规则可以通过语义查询进程来管理和使用以协助获得更准确的结果。对于另一观点在下面的是在本文中更详细地公开的示例性场景的叙述。在建筑中有许多灯。安装在建筑中的这些灯由智能建筑应用104控制，所述智能建筑应用104定义像图8中所示的那样不仅涵盖灯用设备(在本文中也称为灯)而且涵盖建筑中的一些其它设备的智能建筑本体100。稍后，灯控制应用106试图更新led灯(可调节的或可调光的)，例如，更新固件/软件。因为灯控制应用106特定于灯域，所以可能不知道已经存在由智能构建应用104定义的本体，灯控制应用106将使用它自己的语言(即，本体)。因此，它像图9中所示的那样定义另一本体。为了更新目标灯，初始步骤是为了找到led灯(例如，在此场景中为所有led灯，但是设想了某种类型的led灯等)。在两个本体中使用不同的术语(例如，亮度可调节的是智能建筑本体中的布尔属性与brightness_adjustable灯是灯的子类相对)。在没有推理的情况下，onem2mcse124可能无法找到一些灯，因为来自灯控制应用106的查询在灯控制本体105中，然而表示其它灯的rdf三元组在由智能建筑应用104创建的智能建筑应用104中。因此，应该使用推理来找到其它灯。图7的方法可以如下。如所示在智能建筑应用104、onem2mcse124和灯控制应用106之间存在通信。在步骤110处，智能建筑应用104可以发送用于像图8a中所示的那样定义智能建筑本体100的消息。在步骤111处，灯控制应用106可以发送用于关于灯域定义本体101的消息。在步骤112处，智能建筑应用104可以发送利用建筑中的灯的元数据来经由根据本体100的语义注释创建rdf三元组的消息。在步骤113处，灯控制应用106可以基于本体101发起语义查询以遍及由智能建筑应用104插入的rdf三元组找到led和可调节灯(推理应该被触发)。在步骤114处，一旦推理被应用，onem2mcse124就返回那些led可调节灯作为对来自灯控制应用106的查询的响应。第一场景是在语义智能建筑灯控制的背景下。图8a图示用于智能建筑中的事物(例如，地板、房间、灯或传感器)的示例性本体100，其中灯103被定义为设备102的子类并且图7的智能建筑应用104定义图8a和图8b的本体100。图8a图示本体101的一部分。在第一场景中，灯控制应用106可以定义用于灯105的本体101，其被示出在图9中。为了节约电力，灯控制应用106可以确定是否调节一些灯的亮度，而不是接通更多的灯。led灯可以是优选的并且可能优选的是所选择的光也是brightness_adjustable_light。因此，定义本体101的灯控制应用106可首先遍及基于本体100注释的rdf三元组发起语义查询。然而，本体100未显式地指定灯是否是led灯和brightness_adjustable灯。本体100仅定义性质“kind”和“brightness_adjustable”来描述灯103；然而led灯和brightness_adjustable灯被定义为本体101中的灯105的两个子类。在常规系统中这种不同的词汇可以防止定义本体101的灯控制应用106发现智能建筑中期望的灯103，其中灯103由本体100定义。在语义推理的帮助下，可以定义推理规则如下，以用于方便用于rdf三元组的turtle格式的语义查询：1.{？lightontology100:kind“led”}＝>{？lightrdf:typeontology101:led_light}2.{？lightontology100:brightness_adjustabletrue}＝>{？lightrdf:typeontology101:brightness_adjustable_light}第一规则意味着根据本体101其“kind”(如本体100中所定义的)为“led”的任何灯103(以问号开始的任何字符串是变量)也必须是“led_light”。注意的是，诸如本体100的命名空间(前缀)可以与关系“kind”相关联以便指示在本体100内定义了此关系。其它本体可以定义相同的“kind”关系但具有不同的含义。类似地，第二规则规定其属性“brightness_adjustable”(基于本体100)为真的任何灯103必须是本体101中的“brightness_adjustable_light”。在第二场景中，服务提供商分发许多不同类型的传感器以给环境监测服务提供实时温度、湿度、空气质量数据等。因此，来自不同域的应用可出于不同目的得到最新信息。旅行者可以得到其旅游目的地的最新温度和湿度。智能家电可以得到温度和湿度以动态地配置空调。或者环境机构可以检索最新空气质量数据以用于环境监测。图10图示基于第二场景的示例性流程描述。如所示在高级空气质量传感器121、onem2mcse124和环境监测应用123之间存在通信。在步骤126处，可以将推理规则插入到图11的本体130中。在步骤127处，可以基于本体130生成语义描述(一些三元组可以基于所插入的推理规则—推理被触发)。在步骤128处，可以存在要基于图12的本体136从多功能空气质量传感器中找到报告数据的语义查询。在步骤129处，onem2mcse124返回传感器作为对步骤128的查询的响应。语义描述是在传感器基于如图11中所示的本体130报告最新测量样本时生成和附加的，所述本体130由服务提供商定义。例如，可以将高级空气质量传感器121定义为空气质量传感器132的子类。高级空气质量传感器被定义为能够测量空气中的多种有毒成分，例如一氧化碳(co)、二氧化碳(co2)和二氧化氮。参考图10，环境监测应用123可以寻找能够测量空气中的多种有毒成分的传感器。可以专用于环境监测域的本体136(图11)可以将这种传感器类型定义为多功能(例如，类本体136：multi-functionairqualitysensor)。为了方便来自环境监测器域的语义查询，可以添加附加信息以连接相应本体之间的两个概念。具体地，能像图12中所示的那样在此示例中使用owl:equivalentclass。集成此信息的一个方式是当本体136被发布到m2m系统时将它插入到本体130中，如图11中所示。图10图示在步骤127中做语义推理并且对在步骤127中生成的语义信息执行语义查询(步骤128)的流程。在常规系统中，没有用于定义如何触发推理规则的插入(步骤126)并且执行推理(步骤127)以基于推理规则生成更多的语义信息的机制。将通过推理进程来推断一些新语义信息。例如，给定推理规则：{？lightontology130:kind“led”}＝>{？lightrdf:typeontology136:led_light}，如果存在如下基于本体130描述的灯：lightaontology130:kind“led”，则还可以存在再一个三元组(语义信息)：lightardf:typeontology136:led_light。在下面的是关于与常规语义推理和查询系统相关联的一些问题的附加讨论。如在上面的第一场景和第二场景中所图示的，为了在m2m服务层语义框架内实现语义推理，存在推理规则的配置。常规机制在做以下各项时有麻烦：1)组织并构造推理规则以便高效地利用语义推理能力并且影响其它进程(例如，语义查询)的结果；以及2)以减少其它语义信息和本体的利用的效果的方式动态地管理推理规则。对于常规系统，缺少用于触发并执行推理的机制负面地影响语义功能性。在常规系统中，语义查询被广泛地认为是可以触发语义推理的主要事件或进程。在常规系统中未充分地定义以积极方式进行语义推理(例如，在没有诸如语义查询的任何外部触发器的情况下在内部被触发)的机制。如在本文中更详细地讨论的，以积极方式进行语义推理对以下情况来说可以是有帮助的：1)当不知道推理能力的应用发起语义查询时；以及2)当频繁地查询一组语义信息时—积极地运行推理进程可以基于重复相同的推理进程节约开销。在本文中使用不同类型的触发器，所述触发器可以产生与在常规系统中不同的用于执行推理进程的过程和步骤。如灯和传感器用例中所示，添加新本体或新类可以触发规则的创建。触发器可能是语义查询请求，使得推理进程被触发以用于像两个用例中所讨论的那样发现期望的信息。这可以被认为是外部触发器的示例。对于内部触发器，语义注释是一个示例。例如，关于内部触发器，当一些rdf三元组被创建时，那么可以积极地触发推理进程，并且基于推理规则和要创建的三元组集创建另一组三元组。继续参考与常规语义推理和查询系统相关联的问题，一般地通过语义推理进程来生成新信息。例如，在与图10至图12相关联的第二场景中，生成新三元组以根据推理规则将高级空气质量传感器121描述为多功能空气质量传感器。然而，在常规系统中，未定义处理并存储重新生成的信息的机制。鉴于前述问题和场景，在本文中考虑以下内容：1)涉及不同的本体和关系的不同的推理规则可以被应用于同一组三元组，因此，从访问控制观点来看，通过推断所获得的新信息不应该与用于获得该信息的三元组存储在一起；并且2)除了元数据之外还可以生成一些新数据内容—因为数据内容是不透明的，所以添加元数据(例如，给内容数据作注释)以使它变得可理解的机制是优选的。应理解的是，执行本文中图示的步骤的实体(诸如图7、图10和图14至图20)可以是逻辑实体。步骤可以被存储在诸如图24c或图24d中图示的那些的设备、服务器或计算机系统的存储器中，并且在诸如图24c或图24d中图示的那些的设备、服务器或计算机系统的处理器上执行。在示例中，利用在下面关于m2m设备的交互的进一步细节，图7的灯控制应用106或智能建筑应用104及应用160可以驻留在图24a的m2m终端设备18上，同时图13的语义推理引擎142和推理规则管理器143可以驻留在图24a的m2m网关设备14上。设想了跳过步骤、组合步骤或者在本文中公开的示例性方法之间添加步骤(例如，图7、图10和图14至图20)。在下面讨论的是功能架构(图13)以及突出m2m服务层系统内的语义推理进程的方法流程(图14)。方法流程包括在下面更详细地讨论的多个主要过程。图13图示m2m系统中的语义推理处理器(srp)141的示例性功能架构。srp141的全部或部分可以被包括在图5中所示的推理块200中。srp141可以包括语义推理引擎142和推理规则管理器143。语义推理引擎142负责通过基于推理规则应用逻辑来执行推理进程。语义推理引擎142可以从推理规则储存库中获得推理规则，从本体储存库中导出本体定义中的适当类/关系，并且对存储在语义储存库中的目标数据集执行推理进程(例如，推论和推断)。用于推理进程的触发可以来自内部实体或者在推理处理器之外，例如，语义查询和语义注释进程。将在本文中更详细地讨论这个功能性。srp141的推理规则管理器143负责管理(例如，创建、更新或者删除)在通过语义推理进程使用的推理规则储存库中维护的推理规则。推理规则管理器143可以基于外部或内部事件触发管理过程。将在本文中更详细地讨论这个功能性。继续参考图13，推理规则储存库144可以被一般地认为是存储并维护推理规则的地方。语义推理引擎142和推理规则管理器143可以检索所期望的用于规则管理和执行推理进程的推理规则。推理规则储存库144可以是集中式的、分布式的或混合的。在示例中，推理规则储存库144可以被与本体一起以物理方式放置在本体储存库145中，或者被放置在单独的计算设备中。图14图示包括语义推理进程的多个主要过程的高级流程。方法流程一般地图示与推理进程有关的交互。一些方法流程被暗示或者抽象(例如，未示出本体储存库中的本体管理)。推理规则管理(步骤151至步骤153)：在步骤151处，内部或外部触发事件由推理规则管理器143接收以启动规则管理进程(创建、删除或者更新)。在步骤152处，推理规则管理器143然后从本体储存库中检索本体定义以验证新规则。如果验证通过，在步骤153处，则储存库规则管理器143请求在推理规则储存库144中实际地创建、删除或者更新推理规则。语义推理进程(步骤154至步骤157)：在步骤154处，内部或外部触发事件由语义推理引擎142接收以启动推理进程(例如，在一组语义信息上应用通过推理规则定义的逻辑)。语义推理引擎142与推理规则储存库144进行通信(步骤155)并且与本体储存库145进行通信(步骤156)以找到可用的推理规则。在步骤157处，语义推理引擎142向语义储存库146发送要在目标数据集上应用推理规则的请求。在步骤158处，在推理进程完成之后，语义推理引擎142可以向语义储存库146发送要存储通过推理进程生成的新语义信息的请求。是否做这个取决于通过应用或m2m服务层系统的配置。语义储存库146在存储新信息之后响应。在下面讨论的是推理规则管理。可以存在不同类型的推理规则，诸如类型1或类型2。类型1推理规则定义相同本体中的关系或类之间的逻辑。例如，如与图7相关联的第一场景中所图示的，如果led灯是亮度可调节的，则可以将类型1推理规则定义如下：{？lightrdf:typeontology101:led_light}＝>{？lightrdf:typeontology101:brightness_adjustable_light}。类型2推理规则定义不同的本体(两个或更多个本体)中的关系或类之间的逻辑。例如，在与图7相关联的第一场景中呈现的推理规则是类型2推理规则，因为它跨越两个不同的本体。可以将类型2推理规则定义如下：{？lightontology100:kind“led”}＝>{？lightrdf:typeontology101:led_light}。在下面讨论的是推理规则的创建。如这里所讨论的创建不一定意味着m2m系统创建推理规则；替代地m2m系统可以创建用于存储推理规则的条目。m2m系统中的服务层实体(例如，onem2m中的cse)可能无法理解底层语义语法(例如，rdf/rdfs中定义的rdf模式、类和性质)，但是执行crud操作以管理m2m系统内的推理规则。存在可以触发新推理规则的创建的多个情况。在情况1中，新本体被发布并存储在m2m系统中，并且在新本体中的关系/类与m2m系统中的现有本体的关系/类之间创建新推理规则。在这种情况下，新推理规则可以是类型2。在情况2中，在现有本体中定义新关系/类，并且在此新关系/类与现有关系/类之间创建新推理规则。在这种情况下，新推理规则可以是类型1或类型2。图15图示当新本体被发布并存储在m2m系统中(例如，情况1)时创建类型2推理规则的示例性方法。在步骤161处，本体100已经被存储在m2m系统中。同时，应用160通过本体发现进程来发现本体100(步骤161)。当应用160想要弄清楚是否有可能在本体之间创建一些推理规则时，诸如当应用160想要向m2m系统发布新本体时，可以触发本体发现进程。在步骤162至步骤164处，应用160与本体储存库145交换请求和响应消息以将新本体101发布并添加到m2m系统中。特别地在步骤162处，应用160可以向本体储存库发送用于创建本体101的请求消息。在步骤163处，创建本体101。在步骤164处，向应用160发送响应消息，所述响应消息可以包括确认本体101的创建的消息。步骤164的响应可以包括对被创建并存储在本体储存库145中的本体的引用(例如，url)。在步骤165处，一旦应用160得到确认本体101已被成功地添加到m2m系统的响应，应用160就可以向推理规则管理器143发送用于创建在本体100与本体101之间建立某些逻辑关系的推理规则的请求。可以被包括在步骤165的请求消息中的参数可以包括推理规则类型(在此示例中为类型2)、对本体(或这些本体)的引用(例如，uri)、推理规则、推理规则的格式或用于存储推理规则的地方等等。推理规则类型指示在步骤165的请求中创建的推理规则的类型并且暗示涉及多少本体。这提供由推理规则管理器143做的验证的方式，所述验证将推理规则与所涉及的类型和本体相比较。对本体或这些本体的引用提供访问定义推理规则中涉及的类/关系的本体的引用(例如，uri)。推理规则指示在一个或两个本体中定义的类/关系之间的逻辑。关于与图7相关联的场景呈现示例。推理规则的格式指示表示推理规则以帮助应用160或其它实体理解并应用推理规则的格式。它可以是标准格式(例如，rif)或非标准格式。用于存储推理规则的地方指示在哪里存储推理规则。推理规则储存库144是功能数据库，这意味着推理规则可以被实际地存储在另一物理数据库中。如果应用160未指定在哪里存储新推理规则，则规则管理器可以将新规则存储在默认地方中。例如，类型1推理规则可以被存储在定义了本体的本体储存库145中，因为类型1规则指定相同本体中的类/关系之间的某种逻辑。对于指示跨越不同本体的逻辑关系的类型2推理规则，它能被存储在推理规则储存库144内。在哪里创建并维护推理规则通常由推理规则管理器143决定。参考步骤165，可以实现替代方式来将步骤165的请求与在步骤162中发出的请求组合。应用160可以通过发送一个请求消息来请求发布本体并将推理规则创建到系统中。在那种情况下，本体储存库145可以直接地向推理规则管理器143发送用于在推理规则储存库144中创建新规则的请求。在步骤166处，推理规则管理器143可以在创建新推理规则之前验证步骤165的请求。验证可以包括检查以下内容：应用160是否被允许创建推理规则，类或关系在参考本体中是否有效或用于存储推理规则的期望的地方是否有效且可访问等等。在步骤167处，基于验证通过，推理规则管理器143将请求发送到推理规则储存库144以创建新推理规则。请求消息承载包括在步骤165的请求中的内容和参数中的一个或多个。在步骤168处，可以创建新推理规则并将它存储在推理规则储存库144中。在步骤169处，可以向推理规则管理器143以及应用160返回响应消息，所述应用160发起了用于创建新推理规则的请求。在步骤169的响应中，可以包括对新推理规则的引用，使得推理规则管理器143和应用160(即，在这种情况下为始发者)可以访问用于其它操作(例如，删除或禁用)的规则。引用可以是uri或唯一id。图15参考类型2，但是创建类型1推理规则遵循几乎相同的过程但有几个差异。第一差异是本体100不一定被预先配置并存储在系统中(例如，步骤161)。更一般地，应用160可能不需要发现本体100，因为类型1推理规则揭示一个本体内的关系。第二差异是步骤165的请求消息的参数包括类型1规则中涉及的关系或类。这些类或关系被定义在相同本体中。此外，应该将指示推理规则的类型的参数从类型2改变为类型1。如早先所提及的，新推理规则特别是类型1规则被与本体定义一起存储在本体储存库145中。在这种情况下，推理规则管理器143可以与本体储存库145进行通信以便存储新规则，例如，图15中的步骤166和步骤167。此外，假定了发布/管理本体的相同应用在这里做出推理规则。不同的应用也可能首先发现并理解本体，然后使推理规则与管理本体的实体相比较。换句话说，做出推理规则的应用可以是与创建本体的应用不同的应用。一般而言，对类型1规则和类型2规则两者来说情况可以是这样的。图16图示在本体被更新时创建类型2推理规则的示例性方法(例如，情况2)。在步骤170处，本体100和本体101被存储在系统中。这是假定的，因为呼叫流程示出连接两个本体的类型2推理规则的创建。在步骤171至步骤173处，应用160发送要更新本体101的请求，例如，将关系或类添加到本体101中。在图16的步骤174至步骤178处，应用160遵循图15的步骤165至步骤169以在本体101被成功地更新之后在规则储存库中创建新推理规则。图15示出针对情况1创建新规则的过程，其中新本体被发布并存储在m2m系统中，并且在新本体中的关系/类与m2m系统中的现有本体的关系/类之间创建新推理规则。图16示出针对情况2创建新规则的过程，其中在现有本体中定义新关系/类，并且在此新关系/类与现有关系/类之间创建新推理规则。对情况1来说，规则是类型2。对情况2来说规则可能是类型1或类型2。创建新规则的过程可以是相同的，触发器是不同的。图17图示用于在本体被更新(例如，类被删除或者关系被更新)时删除推理规则的示例性方法，其影响推理规则，因为推理规则用经更新的类/关系定义某个逻辑。当本体中的某个关系或类被删除或者本体被移除时，可能的是需要删除一些推理规则。在步骤180处，创建本体100和本体101，并且在连接本体100和本体101中的类/关系的推理规则储存库144中维护推理规则。在步骤181至步骤183处，应用160通过联系本体储存库145来更新本体101中定义的某个类/关系。在步骤184处，应用160发送要删除与已被更新的本体101中的类/关系有关的推理规则的请求。在这种情况下，请求消息可以包含到相关类/关系或通配符信息的链接。通配符信息可以用于删除规则的列表。例如，如果在步骤181中删除类a，则应用160可以提供在步骤184中要求删除涉及类a的所有推理规则的通配符信息。还可能的是步骤184的原因是因为应用160想要删除具体推理规则。在这种情况下，应该在请求中提供用于标识目标推理规则的引用，例如规则id或url。还可能的是假定本体储存库145能够在本体被更新或者删除时检测删除推理规则的必要性，本体储存库发送步骤184的这个请求以删除受本体更新影响的推理规则。在步骤185处，推理规则管理器143通过检查应用160是否有权删除推理规则、检查目标推理规则是否存在、检查目标推理规则是否有效等来验证请求。在步骤186至步骤188处，推理规则管理器143请求推理规则储存库144删除目标推理规则并且从推理规则储存库144向推理规则管理器143和应用160返回响应。注意的是，在步骤187中删除推理规则可能导致基于所删除的推理规则删除蕴涵的操作。为了方便这些操作，提议将蕴涵(例如，通过推理进程推断的新语义信息)与原始语义信息单独地存储，并且每个推理规则维护到基于规则而生成的推断信息的链接。在示例中，关于被单独地存储，原始信息可以被存储在具有url：/triplestore/original_data_1的triplestore中。然后一些蕴涵可以通过应用推理规则基于原始数据来生成，并且被存储在具有不同url：/triplestore/entailements_1的triplestore中。稍后，能对这两个单独的数据集执行crud操作。更新推理规则可以触发一些进一步的操作，诸如更新基于经更新的推理规则而生成的语义信息。这种操作可以针对推理规则与推断语义信息之间的同步引发显著开销和复杂性。因此，应该避免直接地更新推理规则。替代地，可以通过创建新推理规则同时必要时维护或者删除旧推理规则来完成这个。如果旧规则被删除，则还像上面所陈述的那样删除基于旧规则的推断信息。在下面讨论的是关于语义推理进程的触发的细节。可以以按需或积极方式触发并执行语义推理进程。例如，应用或客户端可以发起语义查询请求，所述语义查询请求可以触发推理进程做某种推断和推论，使得可以提取一些隐式信息并且将一些隐式信息作为语义查询结果的一部分返回。当应用正尝试在语义图暂存器中创建一些语义信息时，语义注释还可以积极地触发语义推理进程。注意的是，可以连同其它进程(例如，语义查询和语义注释)一起触发并执行推理进程。此部分中介绍的语义注释和语义查询进程方法不包含关于这些进程的细节。图18图示通过语义查询进程触发的语义推理进程的示例性方法。在步骤211处，应用160通过向语义查询引擎147发送请求来发起语义查询进程。在步骤211的请求中，与语义推理有关的参数可以包括：推理实现指示、通过语义推理来处理新信息的方法、推理能力要求、对推理引擎的引用、规则返回要求、语义推理规则或本体列表。继续参考步骤211，推理实现指示可以指示应用是否想要在查询期间实现(例如，触发)推理进程。参数“通过语义推理来处理新信息的方法”可以是处理并处置经由推理进程而生成的新语义信息的方式的指示。潜在的处理方式可以包括：1)将新元数据永久地存储在m2m系统或语义图暂存器148中；2)通过创建一些语义信息(例如，rdf三元组)来注释新内容数据(若有的话)；3)返回新语义信息而不存储在m2m系统或语义图暂存器148中；或者4)通过应用由原始数据集使用的相同的访问控制策略来将所有新数据存储在新的单独的数据集中。如果应用160实现推理进程则推理能力要求可以指定什么推理能力是期望的。可以定义不同类型的推理能力，诸如rdfs推断、owl推断或一般推理器(例如，支持用户定义的推理规则)。对推理引擎的引用可以指示应用160期望使用哪一个语义推理处理器141来执行推理进程。不同的推理引擎可以具有不同的推理能力、不同的支持格式和不同的接口(例如，restful)。如果未指定这个，则可以使用默认推理引擎。注意的是，推理引擎可以是通过m2m服务层平台可获得的现有引擎(例如，pellet、hermit、vampire)或相同引擎的不同实例。规则返回要求可以指示应用160是否期望得以被通知在推理进程中使用哪一个规则。如果设置了规则返回要求，则可以在步骤221中将所使用的规则连同查询结果一起返回给应用160。语义推理规则可以允许应用以实时方式指定一些自定义规则。语义推理规则在用于推理的系统中维护的推理规则之外。本体列表可以包含被用于发现有用的推理规则的本体的列表。可以存在涉及相同关系/类的许多推理规则，但是应用160可能对所有这些不感兴趣。通过指定此列表，应用160可以限制从推理规则储存库144中找到的推理规则的数目，并且使与推理进程相关联的显著开销最小化。例如，智能家庭应用(例如，应用160)可能想要在家里找到空气质量传感器，并且它可以在发现有用的推理规则时从列表中排除为农业和医疗保健域所定义的本体，因为它不会对为那两个域所生成的新信息感兴趣。继续参考图18，在步骤212处，在接收到查询请求时，语义查询引擎147检查推理实现指示。如果未实现语义推理，则语义查询引擎147仅遵循常规查询进程来处理语义查询请求。如果推理被实现(例如，应用160期望连同查询进程一起执行语义推理)，则语义查询引擎147可以检查应用160是否有权将语义推理用作服务。在步骤213处，如果语义查询引擎147找出应用160被允许连同语义查询一起触发推理，则语义查询引擎147可以向语义推理处理器141发送请求。如果应用160在步骤211的请求中未指定对语义推理处理器的引用，则语义查询引擎147可以使用默认推理处理器或者发起发现进程以找到可用的推理处理器。在步骤214处，语义推理处理器141在它接收到步骤213的用于触发推理进程的请求时识别潜在有用的推理规则。为了识别有用的推理规则，规则管理器可以查找与语义查询进程中涉及的本体有关的规则。语义查询可以包含前缀定义中的本体集以及查询主体。在步骤215处，为了获得有用的推理规则，语义推理处理器141可以向推理规则储存库144发送要检索有用的规则的请求。请求消息可以包括请求中的来自应用160的语义查询，使得规则管理器可以返回与在对应本体中定义的查询中涉及的类或关系有关的推理规则。如早先讨论的，在推理规则储存库144与本体储存库145位于一处的情况下，步骤215处的请求转向本体储存库145以检索潜在的推理规则。继续参考图18，在步骤216处，推理规则储存库144可以返回可能在响应中有帮助的推理规则，诸如响应中的规则的数目、推理规则的列表以及对其它规则储存库的引用。响应中的规则的数目可以指示有多少规则被识别并作为潜在有用的推理规则返回。推理规则列表可以被认为是已被找到的推理规则的列表。如果语义推理处理器141期望找到更多有用的推理规则或者在当前推理规则储存库144中未找到推理规则，则对其它规则储存库的引用可以参考另一推理规则储存库144的访问以便找到附加推理规则。在步骤217处，一旦从推理规则储存库144接收到推理规则，语义推理处理器141(例如，推理引擎)通过将推理规则集成到查询中来更新语义查询，使得可以针对该查询返回更多的信息。例如，图7的灯控制应用106可以发起sparql查询以找到建筑中的led灯。originalsparqlquery:select？lightwhere{？lightrdf:typeontology101:led_light}给出参考与图7相关联的第一场景而呈现的以下推理规则：{？lightrdf:typeontology101:led_light}＝>{？lightontology100:kind“led”}，语义推理处理器可以更新语义查询如下：updatedsparqlquery:select？lightwhere{？lightrdf:typeontology101:led_light？lightrdf:typeontology100:light？lightontology100:kind“led”}通过关于步骤217做这个，如果基于智能建筑本体100呈现实际的语义信息(例如，rdf三元组)则查询可以返回一些信息。换句话说，这实现不同域/垂直面(例如，智能建筑和灯控制)之间的互操作性。可能的是基于本体100描述智能建筑中的设备和器具；然而来自灯域的灯控制应用106期望基于本体101表达语义信息。推理规则然后连接针对同一事物具有不同术语/词汇表的两个域。在没有这种推理规则和推理能力的情况下，灯控制应用106可能找不到灯，因为语义信息基于本体100。在步骤218处，语义推理处理器141将经更新的语义查询返回到语义查询引擎147。还可能的是语义推理处理器141将经修改的语义查询发送到语义图暂存器148。在这种情况下，从语义推理处理器141到承载经更新的语义查询请求的语义图暂存器148组合步骤218和步骤219。在步骤219至步骤221处，语义查询引擎147联系语义图暂存器148以对目标数据集执行语义查询(步骤220)，所述语义图暂存器148将查询的结果返回到语义查询引擎147和应用160。继续参考图18，可替选地，语义推理处理器141可以在经更新的查询中排除原始查询的内容(步骤217)，并且可以将请求直接地发送到语义图暂存器148以用于语义查询并且在语义图暂存器148返回查询结果时将更多的三元组添加到查询结果中。除了语义查询进程之外，还可以通过语义注释进程来触发语义推理进程。m2m资源的语义注释是用于向m2m资源添加语义信息(例如，元数据、rdf三元组)以便向异构m2m应用提供一致数据转换和数据互操作性的方法。例如，2016年1月8日星期五费城的温度可以是20华氏度。值20是数据内容，其对应用而言是透明的。其它信息(例如，单位、时间或位置)是描述数据内容值20的元数据。在没有元数据的情况下，数据内容它本身对来自不同域(例如，智能家庭和智能交通)的应用而言是不透明的，换句话说，应用160可能难以理解内容值20意指什么。应用160可能甚至不知道这是温度测量结果。图19图示通过语义注释进程触发的语义推理进程的示例性方法。在步骤231处，应用160向语义注释处理器149发送语义注释请求以为数据内容创建一些语义信息(例如，rdf三元组)。步骤231的请求可以包含与图18的步骤211中描述的类似的信息。注意的是，当应用160向m2m系统报告数据时步骤231的请求可以与请求集成在一起。例如，当温度传感器向m2m服务器报告最新温度测量结果时，传感器还可以请求语义注释处理器149创建一些元数据(例如，语义信息)以描述实际的温度值(例如，温度测量结果)。此外，可以基于新语义信息在相同消息中实现推理。在步骤232至步骤233处，语义注释处理器149验证应用160是否被允许触发注释，并且如果应用160有权这样做则通过创建语义信息来执行语义注释进程。例如在步骤233处，语义注释处理器149为注释生成新语义信息(三元组)。在步骤234处，在创建语义信息完成时，语义注释处理器149检查在步骤231处接收到的请求中是否实现推理进程，以及应用160(例如，始发者)是否具有用于请求推理进程的权限。在步骤235处，例如，语义注释处理器149向语义推理处理器141发送要在应用160在步骤231中实现推理进程的情况下触发推理进程的请求。在步骤236至步骤238处，语义推理处理器141遵循图18的步骤214至步骤216的类似步骤以通过联系语义推理处理器141的推理规则管理器(例如，推理规则管理器143)来获得有用的推理规则。在步骤239处，语义推理处理器141生成一些新语义信息，所述新语义信息可以基于从推理规则管理器获得的推理规则和在步骤233中注释的语义信息两者。例如，如在与图10相关联的第二场景中所图示的，可以在步骤233中通过以下三元组来描述传感器设备：sensorardf:typeontology136:multi-functionalairqualitysensor。给定在步骤236至步骤238中获得的推理规则：ontology136:multi-functionalairqualitysensorowl:equivalentclassontology130:advancedairqualitysensor。换句话说，本体136中的functionalairqualitysensor与本体130中定义的advancedairqualitysensor相同。可以在步骤239处通过语义推理处理器141来生成附加三元组：sensorardf:typeontology136:advancedairqualitysensor。当一些应用试图基于本体130找到某个空气质量传感器以得到一氧化碳(co)和二氧化碳(co2)测量结果时，此新三元组(:sensorardf:typeontology130:advancedairqualitysensor)方便语义查询。继续参考步骤240，语义推理处理器141与通过推理进程所生成的新语义信息一起向语义注释处理器149发送响应。在步骤241处，语义注释处理器149向语义图暂存器148发送用于存储新语义信息的请求。在步骤242处，语义图暂存器148存储新三元组。在步骤243处，语义图暂存器148将与步骤241相关联的响应消息发送到语义注释处理器149和应用160。在步骤243的响应消息中，语义图暂存器148可以指示通过注释所生成的语义信息被存储在与通过推理所生成的语义信息相同的地方并且提供对存储有新语义信息的数据集的引用。此外，如果原始信息也被存储在m2m系统(例如，onem2mroa中的资源树)中，则从语义注释处理器149到应用160的响应可以包含对原始信息(例如，步骤231中的信息请求或在步骤233中生成的三元组)的引用。语义推理进程可以通过应用通过推理规则所表示的逻辑来生成蕴涵。蕴涵是从语义注释数据导出的隐式知识。取决于配置和要求，可能需要将蕴涵存储在语义图暂存器(例如，triplestore)中。这里呈现的是用于假定蕴涵将被存储在语义图暂存器中来处理蕴涵的一些方法(例如，配置访问控制策略或存储)。取决于重新生成的信息是数据内容还是元数据，不同的步骤被执行。图20图示处置蕴涵的示例性方法。在步骤250处，完成推理进程(例如，已经生成蕴涵)。在步骤251处，语义推理引擎142在确定接下来的步骤之前检查蕴含是数据内容(例如，过去一周的温度的平均值)还是元数据。在包括步骤252至步骤257的情况258中，新蕴涵是元数据(例如，语义信息或三元组)。在步骤252处，在存储蕴涵之前，访问控制策略信息可以与新蕴涵相关联。语义推理引擎142发送要基于哪些蕴涵被生成来检索应用于原始语义信息的访问控制策略信息的请求。例如，哪一个应用被允许创建并删除原始数据，在某个ip地址集下或在区域内的哪一个应用被允许检索原始数据。这是访问控制信息的示例。这里假定了相同的访问控制策略被用于原始语义信息和新推断信息(例如，蕴涵)。因此，步骤252的请求消息包含对语义图暂存器148中的原始语义信息的引用。在步骤253处，应用于原始语义信息的访问控制策略被发送到语义推理引擎142。步骤253的访问控制信息可以用语义三元组或对资源树中的访问控制策略资源的引用措词。在步骤254处，语义推理引擎142使访问控制策略与新蕴涵(即，新语义信息)相关联。在步骤255处，语义推理引擎142向语义图暂存器148发送要将新蕴涵存储在所期望的地方(例如，与原始语义信息或新数据集相同的数据集)的请求。用于存储新蕴涵的所期望的位置可以由触发语义推理进程的实体配置或者在未指定位置的情况下可以是默认位置。例如，新语义信息(例如，rdf三元组)可以被存储在图暂存器内的单独的数据集(例如，/graphstore/entailments1)中，然而原始语义信息被存储在原始数据集(例如，/graphstore/original_data_set_1)中。在请求中，推理引擎能使用标准格式api来转移信息，诸如sparql更新和http接口。在步骤256处，可以基于步骤255的请求来存储蕴涵。一般而言，蕴涵被存储在来自原始数据的单独的数据集中。单独的存储可以用于容易管理或简单访问控制。关于容易管理，将来可以管理(更新或者删除)蕴涵。如果它们与原始语义信息一起存储，则难以区分语义信息是原始的还是推断的，这可以使管理变得更困难。相应地，每个数据集被创建来通过推理进程存储蕴涵，并且在步骤257中将引用返回到语义推理引擎142。关于简单访问控制，对原始语义信息来说，来自不同域的应用可以使用不同的规则来触发推理进程。这些应用可以具有不同的访问权限，并且如果未经授权，则不应该被允许其访问为其它应用所生成的内容。这可以支持将蕴涵与原始数据单独地存储的原因。在步骤257处，语义图暂存器将响应发送回到推理引擎以确认蕴涵被成功地存储在所期望的数据集中，所期望的数据集可以是新数据集或包含原始信息的数据集。可以将用于访问存储蕴涵的数据集的引用包括在响应中。情况268包括步骤262至步骤267。在步骤262处，如果蕴涵是不透明的数据内容(例如，纯值)，则应该在语义上注释新数据内容。例如，基于温度、湿度或空气质量的值，可以添加作为数字的舒适指数来描述这些数字，诸如测量温度的时间和地点、温度值的单位(例如，华氏或摄氏)。为了能够理解数字，提供更多的信息(诸如日期或位置)可以是有益的。因此，语义推理引擎142可以向语义注释处理器149发送要触发语义注释进程的请求。该请求可以包括以下信息：1)新数据内容；2)描述新数据内容的信息；或3)对本体的引用，所述本体定义用于注释新数据内容的类和关系。新数据内容的示例可以是通过推理进程基于温度、空气质量和湿度而推断的舒适指数。用于描述新数据内容的信息的示例可以包括新舒适指数的位置或时间。继续参考图20，在步骤263处，语义注释处理器149可以联系m2m资源储存库140和语义图暂存器148来在注释之前检索更多的信息，诸如访问控制策略或到原始语义信息的链接。在步骤264处，语义注释处理器149生成一组新语义信息(例如，用于描述新数据内容的rdf三元组)。在步骤265至步骤267处，语义注释处理器149与语义图暂存器148进行通信以通过注释进程来存储新蕴涵(例如，数据内容)以及新语义信息。用于访问数据集的引用被包括在响应中。更具体地在步骤265处，发送要将新语义信息与蕴涵一起存储在语义图暂存器148中的请求。在步骤266处，语义图暂存器148存储新语义信息和蕴涵。在步骤267处，语义图暂存器148发送响应，所述响应可以包括对将新语义信息存储在图暂存器中的数据集的引用。图21图示onem2mroa中的语义推理器的示例性架构。在下面公开的是示出如何在onem2m面向资源架构(roa)中应用语义推理进程的一些机制。可以将语义推理器272部署为cse271中的csf。可替选地，可以将语义推理器272部署为语义引擎的一部分，所述语义引擎作为包括诸如语义查询、语义注释和语义推理的多个语义相关功能性的cse271中的csf被实现。所提议的csf能被部署在终端设备、m2m网关或m2m服务器处。公开了用于在onem2mroa中实现语义推理能力的新资源<reasoningrule>。在表6中列举属性和子资源(而未列举在onem2m-ts-0001onem2mfunctionalarchitecture-v2.5.0中定义的公共和通用属性)。表6：<reasoningrule>资源的子资源和属性能添加新资源作为<semanticdescriptor>资源、<ae>资源、<container>资源和<contentinstance>资源的子资源、如稍后所介绍的<semanticreasoner>资源或直接在<csebase>资源下。如表6中所示，<reasoningrule>资源可以包含一个或多个<reasoningrule>资源，其中的每一个表示不同的推理规则。这方便实现在一个<reasoningrule>资源下维护所有推理规则的集中式推理规则储存库。还可能的是推理规则被以分布式方式存储。注意的是，一个<reasoningrule>资源还可以在ruledescriptor属性中包含多个规则，但是这些多个规则应该与同一组本体有关。此外，提议<semanticreasoner>资源以指示onem2m系统中部署的推理能力。在表7中列举了属性和子资源。表7：<semanticreasoner>资源的子资源和属性如本文中所讨论的，请求消息可以包含用于方便推理规则管理以及推理进程的一些新参数。为了实现推理规则管理，请求消息的净荷可以包括以下信息：1)reasoningruletype：指示要管理的推理规则的类型，例如创建或删除；2)reasoningrule：推理规则的描述或用于访问推理规则的引用；3)storageuri：用于存储要创建的新推理规则的位置；或4)格式：表达要管理的推理规则的格式，例如rif。为了触发并执行推理进程，现有onem2m请求消息包括如本文所讨论的enablementindication、reasoningcapability或reasoningrulelist。enablementindication指示是否在通过消息请求的操作期间实现推理。例如，当语义查询引擎147接收到语义查询请求时，语义查询引擎147可以联系语义推理处理器141以在推理被实现的情况下启动推理进程；否则语义查询引擎147将查询转发到语义图暂存器148。reasoningcapability指示什么推理能力是优选的，例如，仅rdfs推理或owl推理。这可能有助于选择具有所期望的能力的推理器。在内部或在外部可以有多个推理器可用。reasoningrulelist：推理规则的列表或对要在推理进程中使用的推理规则的列表的引用。这允许应用在请求中指定一个或多个推理规则。这些规则由用户定义并以实时方式提供给推理处理器，这些规则与已经在系统中的那些规则不同。换句话说，此参数包含可能未被存储在系统中的一些用户特定规则。图22图示与作为服务的语义推理相关联的示例性用户接口。参数被定义用于实现并利用本文中所讨论的语义推理服务。用户接口可以被实现用于利用默认值以及用于针对语义推理服务实现或者禁用某些特征的控制开关对那些参数进行配置或编程。块801可以是具有不同应用(诸如语义推理服务应用802、web服务应用803或电子邮件应用804)的设备(例如，m2m设备30)的用户接口。选择语义推理服务应用802可以打开提供选择(诸如推理或规则管理)的窗口806。如本文中所讨论的，与实现语义推理服务相关联的语义推理配置可以被显示在窗口807中。选择窗口807中的文本可以打开提供与选择相关联的附加配置或参数信息的另一窗口809。图23图示可以基于本文中所讨论的方法和系统而生成的另一示例性显示(例如，图形用户接口)。显示接口901(例如，触摸屏显示器)可以在块902中提供与像本文中所讨论的那样实现语义推理服务相关联的文本，诸如表6和表7的参数。在另一示例中，可以在块902中显示本文中所讨论的步骤中的任一个的进展(例如，发送的消息或步骤的成功)。此外，可以在显示接口901上显示图形输出903。图形输出903可以是设备(例如，传感器)的拓扑、本文中所讨论的任何方法或系统的进展的图形输出、本体(例如，图8a或图8b)的图形输出等。图24a是可以在其中实现与实现语义推理服务相关联的一个或多个公开的构思(例如，图7至图20和随附讨论)的示例机器到机器(m2m)、物联网(iot)或万维物联网(webofthings)(wot)通信系统10的图。一般地，m2m技术为iot/wot提供构件，并且任何m2m设备、m2m网关或m2m服务平台可以是iot/wot以及iot/wot服务层的组件等。如图24a中所示，m2m/iot/wot通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、isdn、plc等)或无线网络(例如，wlan、蜂窝等)或异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息、广播等的内容的多个接入网络。例如，通信网络12可以采用一个或多个信道接入方法，诸如码分多址(cdma)、时分多址(tdma)、频分多址(fdma)、正交fdma(ofdma)、单载波fdma(sc-fdma)等。另外，通信网络12可以包括诸如例如核心网络、因特网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或企业网络的其它网络。如图24a中所示，m2m/iot/wot通信系统10可以包括基础设施域和现场域。基础设施域指代端到端m2m部署的网络侧，而现场域指代通常在m2m网关后面的区域网络。现场域包括m2m网关14和终端设备18。应领会的是，可以按需在m2m/iot/wot通信系统10中包括任何数目的m2m网关设备14和m2m终端设备18。m2m网关设备14和m2m终端设备18中的每一个均被配置成经由通信网络12或直接无线电链路发送和接收信号。m2m网关设备14允许无线m2m设备(例如，蜂窝的和非蜂窝的)以及固定网络m2m设备(例如，plc)通过运营商网络(诸如通信网络12或直接无线电链路)来通信。例如，m2m设备18可以收集数据并且经由通信网络12或直接无线电链路将数据发送到m2m应用20或m2m设备18。m2m设备18还可以从m2m应用20或m2m设备18接收数据。另外，如下所述，可以经由m2m服务层22向m2m应用20发送数据和信号并且从m2m应用20接收数据和信号。m2m设备18和网关14可以经由包括例如蜂窝、wlan、wpan(例如，zigbee、6lowpan、蓝牙)、直接无线电链路和有线线路的各种网络来通信。参考图24b，现场域中图示的m2m服务层22(例如，如本文中所描述的图7或图10的onem2mcse)为m2m应用20(例如，应用160或灯控制应用106)、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’可以由一个或多个服务器、计算机、虚拟机(例如，云/计算/存储场等)等实现。另外参考图24b，m2m服务层22和22’提供各种应用和垂直面可利用的核心服务递送能力集。这些服务能力使得m2m应用20和20’能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全、计费、服务/设备发现等的功能。基本上，这些服务能力使应用免于实现这些功能性的负担，从而简化应用开发并减少成本和上市时间。服务层22和22’还使得m2m应用20和20’能够连同服务层22和22’提供的服务一起通过各种网络12和12'来通信。在一些示例中，m2m应用20和20’可以包括使用如本文中所公开的实现语义推理服务的方法或系统来通信的期望应用。m2m应用20和20’可以包括诸如但不限于交通、健康和保健、连网家庭、能源管理、资产跟踪以及安全和监视的各种行业中的应用。如上面所提及的，跨越系统的设备、网关和其它服务器运行的m2m服务层支持诸如例如数据收集、设备管理、安全、计费、位置跟踪/地理围栏、设备/服务发现和传统系统集成的功能，并且将这些功能作为服务提供给m2m应用20和20’。可以将本申请的实现语义推理服务的方法或系统实现为服务层的一部分。服务层是通过一组应用编程接口(api)和底层联网接口来支持增值服务能力的中间件层。m2m实体(例如，诸如在硬件上实现的设备、网关或服务/平台的m2m功能实体)可以提供应用或服务。etsim2m和onem2m两者都使用可以包含本申请的实现语义推理服务的方法或系统的服务层。onem2m服务层支持一组公共服务功能(csf)(即，服务能力)。一组一种或多种具体类型的csf的实例化被称为公共服务实体(cse)，所述cse可被托管在不同类型的网络节点(例如，基础设施节点、中间节点、应用特定节点)上。另外，可将本申请的实现语义推理服务的方法或系统实现为使用面向服务架构(soa)或面向资源架构(roa)来访问诸如本申请的实现语义推理服务的方法或系统的服务的m2m网络的一部分。如本文中所公开的，术语“服务层”可以被认为是网络服务架构内的功能层。服务层通常位于诸如http、coap或mqtt的应用协议层上方并且为客户端应用提供增值服务。服务层还提供到在较低资源层(诸如例如控制层和传输/接入层)的核心网络的接口。服务层支持包括服务定义、服务运行时实现、策略管理、接入控制和服务集群的多个类别的(服务)能力或功能性。最近，多个行业标准组织(例如，onem2m)一直在开发m2m服务层以解决与将m2m类型的设备和应用集成到诸如因特网/web、蜂窝、企业和家庭网络的部署中相关联的挑战。m2m服务层可给应用或各种设备提供对由服务层(其可以被称为cse或服务能力层(scl))支持的上面提及的能力或功能性的合集或集合的访问。几个示例包括但不限于可以被各种应用共同使用的安全、计费、数据管理、设备管理、发现、提供和连接管理。可经由利用由m2m服务层定义的消息格式、资源结构和资源表示的api来给此类各种应用提供这些能力或功能性。cse或scl是可以通过硬件或软件来实现并且提供暴露给各种应用或设备的(服务)能力或功能性的功能实体(例如，此类功能实体之间的功能接口)以便它们使用此类能力或功能性。例如，图24c是示例m2m设备30(诸如m2m终端设备18(其可以包括应用160或灯控制应用106)或m2m网关设备14(其可以包括图13的一个或多个组件))的系统图。如图24c中所示，m2m设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、键区40、显示器/触摸板42、不可移动存储器44、可移除存储器46、电源48、全球定位系统(gps)芯片组50和其它外围设备52。应领会的是，m2m设备30可以包括上述元件的任何子组合，同时保持与所公开的主题一致。m2m设备30(其可以包括图7至图20的一个或多个组件)可以是执行所公开的用于实现语义推理服务的系统和方法的示例性实施方式。处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(dsp)、多个微处理器、与dsp核心关联的一个或多个微处理器、控制器、微控制器、专用集成电路(asic)、现场可编程门阵列(fpga)电路、任何其它类型的集成电路(ic)、状态机等。处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理，或使得m2m设备30能够在无线环境中操作的任何其它功能性。处理器32可以与收发器34耦合，所述收发器34可以与发送/接收元件36耦合。虽然图24c将处理器32和收发器34描绘为单独的组件，但是应领会的是，处理器32和收发器34可以被一起集成在一个电子封装或芯片中。处理器32可以执行应用层程序(例如，浏览器)或无线电接入层(ran)程序或通信。处理器32可以诸如例如在接入层或应用层处执行诸如认证、安全密钥协定或密码操作的安全操作。发送/接收元件36可以被配置成向m2m服务平台22发送信号或者从m2m服务平台22接收信号。例如，发送/接收元件36可以是被配置成发送或者接收rf信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如wlan、wpan、蜂窝等。在示例中，发送/接收元件36例如可以是被配置成发送或者接收ir、uv或可见光信号的发射器/检测器。在又一个示例中，发送/接收元件36可以被配置成发送并接收rf信号和光信号两者。应领会的是，发送/接收元件36可以被配置成发送或者接收无线信号或有线信号的任何组合。此外，尽管发送/接收元件36在图24c中被描绘为单个元件，然而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上的控制照明图案、图像或颜色可以反映本文中所图示或讨论的图(例如，图7、图9、图14至图20等)中的方法流程或组件中的任一个的状态。本文中公开的是实现语义推理服务的消息和过程。除可以在显示器42上显示的消息和进程之外，还可扩展这些消息和过程以提供用于用户经由输入资源(例如，扬声器/麦克风38、键区40或显示器/触摸板42)请求语义推理服务相关资源并且请求、配置或者查询资源的语义推理服务相关信息的接口/api。处理器32可以从电源48接收电力，并且可以被配置成分配或者控制到m2m设备30中的其它组件的电力。电源48可以是用于给m2m设备30供电的任何适合的设备。例如，电源48可以包括一个或多个干电池蓄电池(例如，镍镉(nicd)、镍锌(nizn)、镍金属氢化物(nimh)、锂离子(锂离子)等)、太阳能电池、燃料电池等。处理器32还可以与gps芯片组50耦合，所述gps芯片组50被配置成提供有关m2m设备30的当前位置的位置信息(例如，经度和纬度)。应领会的是，m2m设备30可以通过任何适合的位置确定方法来获取位置信息，同时保持与本文中所公开的信息一致。处理器32还可以与其它外围设备52耦合，所述其它外围设备52可以包括提供附加特征、功能性或有线或无线连接的一个或多个软件或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物计量(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于相片或视频)、通用串行总线(usb)端口或其它互连接口、振动设备、电视收发器、免提耳机、模块、调频(fm)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等。可以将发送/接收元件36具体实现在其它装置或设备中，所述其它装置或设备诸如传感器、消费电子装置、诸如智能手表或智能服装的可穿戴设备、医疗或电子卫生设备、机器人、工业设备、无人机、诸如汽车、卡车、火车或飞机的交通工具。发送/接收元件36可以经由一个或多个互连接口(诸如可以包括外围设备52中的一个的互连接口)连接到此类装置或设备的其它组件、模块或系统。图24d是例如可以在上面实现图24a和图24b的m2m服务平台22的示例性计算系统90的框图。计算系统90(例如，m2m终端设备18或m2m网关设备14)可以包括计算机或服务器，并且可以主要通过计算机可读指令通过存储或者访问这些指令的无论什么手段来控制。可以在中央处理单元(cpu)91内执行此类计算机可读指令以使计算系统90做工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称作微处理器的单芯片cpu实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主cpu91不同的可选处理器，其执行附加功能或者辅助cpu91。cpu91或协处理器81可以接收、生成并处理与所公开的用于实现语义推理服务(诸如接收触发消息、验证请求、创建推理规则等)的系统和方法有关的数据。在操作中，cpu91取出指令，对指令进行解码并执行指令，并且经由计算机的主数据转移路径(系统总线80)转移到和来自其它资源的信息。这种系统总线连接计算系统90中的组件并且定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断并用于操作系统总线的控制线。这种系统总线80的示例是pci(外围组件互连)总线。与系统总线80耦合的存储器设备包括随机存取存储器(ram)82和只读存储器(rom)93。此类存储器包括允许信息被存储和检索的电路。rom93一般地包含不能容易地被修改的存储的数据。存储在ram82中的数据可由cpu91或其它硬件设备读取或者改变。对ram82或rom93的访问可以由存储器控制器92控制。存储器控制器92可以提供随着指令被执行而将虚拟地址转换成物理地址的地址转换功能。存储器控制器92还可以提供使系统内的进程隔离并且使系统进程与用户进程隔离的存储器保护功能。因此，在第一模式下运行的程序只能访问由它自己的进程虚拟地址空间映射的存储器；除非已建立进程之间的存储器共享，否则它不能访问另一进程的虚拟地址空间内的存储器。此外，计算系统90可以包含负责将来自cpu91的指令传送到外围设备(诸如打印机94、键盘84、鼠标95和磁盘驱动器85)的外围设备控制器83。由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于crt的视频显示器、基于lcd的平板显示器、基于气体等离子体的平板显示器或触摸板来实现。显示控制器96包括生成被发送到显示器86的视频信号所需要的电子组件。此外，计算系统90可以包含可以用于将计算系统90连接到外部通信网络(诸如图24a和图24b的网络12)的网络适配器97。应理解的是，可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式具体实现本文中描述的任何或所有系统、方法和进程，所述指令当由诸如计算机、服务器、m2m终端设备、m2m网关设备等的机器执行时，执行或者实现本文中描述的系统、方法和进程。具体地，可以以此类计算机可执行指令的形式实现上述的步骤、操作或功能中的任一个。计算机可读存储介质包括用任何方法或技术实现以用于存储信息的易失性和非易失性、可移动和不可移动介质，但是此类计算机可读存储介质本身不包括信号。如从本文描述中显然的，存储介质应该被解释为法定主题。计算机可读存储介质包括ram、rom、eeprom、闪速存储器或其它存储技术、cd-rom、数字通用盘(dvd)或其它光盘存储装置、磁盒、磁带、磁盘存储装置或其它磁存储设备，或可用于存储所期望的信息并且可由计算机访问的任何其它物理介质。在描述如图中所图示的本公开的主题-实现语义推理服务-的优选方法、系统或装置时，为了清楚起见采用具体术语。然而，所要求保护的主题不旨在限于如此选择的具体术语，并且应当理解的是，每个具体元件包括以类似方式操作以实现类似目的的所有技术等同物。可以连同硬件、固件、软件或在适当的情况下其组合一起实施本文中描述的各种技术。这种硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置中。装置可以单独或者彼此相结合地操作以实现本文中描述的方法。如本文中所使用的，可以互换地使用术语“装置”、“网络装置”、“节点”、“设备”、“网络节点”等。此外，除非在本文中另外提供，否则一般地排他性地使用单词“或”的用途。此撰写的说明书使用示例来公开本发明，包括最佳模式，并且还使得本领域的技术人员能够实践本发明，包括做出并使用任何设备或系统以及执行任何并入的方法。本发明的可取得专利的范围由权利要求限定，并且可以包括被本领域的技术人员想到的其它示例(例如，跳过步骤、组合步骤或者在本文中公开的示例性方法之间添加步骤)。如果这些其它示例具有确实与权利要求的字面语言不同的结构元件，或者如果它们包括与权利要求的字面语言无实质差异的等效结构元件，则这些其它示例旨在为在权利要求的范围内。如本文中所描述的方法、系统和装置等可以提供用于实现语义推理服务的手段。方法、系统、计算机可读存储介质或装置具有用于进行以下各项的手段：接收用于创建与第一本体和第二本体相关联的推理规则的请求；验证用于创建与第一本体和第二本体相关联的推理规则的请求；基于验证用于创建与第一本体和第二本体相关联的推理规则的请求，提供用于创建推理规则的指令；以及基于用于创建推理规则的请求接收对与第一本体和第二本体相关联的推理规则的引用。用于创建推理规则的请求可以包括推理规则类型。用于创建推理规则的请求可以包括对第一本体或第二本体的引用。用于创建推理规则的请求可以包括推理规则。用于创建推理规则的请求可以包括推理规则的格式。用于创建推理规则的请求可以包括用于存储推理规则的地方。用于创建推理规则的请求可以包括对第一本体或第二本体的引用，其中，引用包括统一资源标识符。用于创建语义推理规则的请求可以基于检测语义注释。方法、系统和装置尤其还可以提供用于基于第一本体的更新来删除所创建的语义推理规则的手段。方法、系统和装置尤其还可以提供用于执行通过语义查询、语义注释或其它触发器触发的本文中公开的语义推理进程的手段。方法、系统和装置尤其还可以提供用于管理(例如，crud)通过语义推理进程所生成的新信息的手段。本段落中的所有组合(包括步骤的移除或添加)是以与详细描述的其它部分一致的方式设想的。当前第1页12当前第1页12