CN108604236A - 语义物联网的restful操作 - Google Patents

Abstract

可以将用于RESTful操作的访问控制提供给集中式语义图存储。另外，可以在资源树数据库中分布的语义三元组上提供操作。在示例中，系统可以使用在分级资源树机制中分布的语义描述符来维护语义描述符关系信息。这些机制使得能够在特定图的上下文内通过一起使用特定的一组语义描述符来执行语义查询。为了语义操作目的而使用组的形成的机制还使得能够使用组资源以便向组成员扇出语义请求，组成员包括位于不同服务实体上的成员。

Description

语义物联网的RESTFUL操作

对于相关申请的交叉引用

本申请要求在2015年10月30日提交的标题为“Restful Operations ForSemantic IOT”的美国临时专利申请序号62/249,112以及在2015年11月9日提交的标题为“Restful Operations For Semantic IOT”的美国临时专利申请序号62/252,940的权益。上述各申请的内容通过引用整体并入本文。

背景技术

语义网

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

语义Web堆栈

语义Web堆栈(参见W3C技术堆栈说明的描述，http：//www.w3.org/Consortium/techstack-desc.html)说明了由W3C指定的语义Web的架构，如图1所示。各组件的功能和关系可概括如下。

XML为文档内的内容结构提供了基本语法，但没有将语义与其中包含的内容的含义关联起来。在大多数情况下，XML目前不是语义Web技术的必要组成部分，因为存在替代语法，例如Turtle。Turtle是事实上的标准，但并没有通过正式的标准化过程。

XML模式是用于提供和限制包含在XML文档中的元素的结构和内容的语言。

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

RDF模式扩展RDF，并且是用于描述基于RDF的资源的属性和类的词汇表，其具有用于这种属性和类的通用层次结构的语义。

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

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

SPARQL 1.1查询是用于RDF图的查询语言，可用于跨不同数据源表达查询，不论该数据是否本地存储为RDF或经由中间件被视为RDF。SPARQL包含查询所必需的能力和可选图模式及其合取和析取。SPARQL还支持聚合、子查询、否定、通过表达式创建值、可扩展值测试以及通过源RDF图约束查询。SPARQL查询的结果可以是结果集或RDF图。

SPARQL 1.1更新是用于RDF图的更新语言。它使用从RDF的SPARQL查询语言派生的语法。对在语义图存储中的图的集合执行更新操作。提供操作来更新、创建并删除语义图存储中的RDF图。

RIF是W3C规则交换格式。它是用于表达计算机可以执行的Web规则的XML语言。RIF提供称为方言的多种版本。它包括RIF基本逻辑方言(RIF-BLD)和RIF产生式规则方言(RIFPRD)。

语义搜索和语义查询

关系数据库仅以隐式方式包含数据之间的所有关系。例如，客户和产品之间的关系(存储在两个内容表中并且与另外的链接表相关联)仅在由开发者编写的查询语句(例如，在关系数据库的情况下使用SQL)中存在。编写查询需要对数据库模式的确切了解。许多关系数据库像在分级数据库中那样被建模，在该分级数据库中，数据被组织为树状结构。数据存储为通过链接相互连接的记录。分级数据库模型中的记录对应于关系数据库模型中的行(或元组)，并且实体类型对应于表(或关系-父&子)。可以由SQL或非SQL搜索引擎进行记录的搜索或查询。

如图2中所示，常规的分级数据库模型要求每个子记录只有一个父记录，而每个父记录可以有一个或多个子记录。为了从分级数据库检索数据，需要从根节点开始遍历整个树。这种结构简单但不灵活，因为这种关系仅限于一对多的关系。

链接数据以明确的方式包含数据之间的所有关系。在关系数据库中描述的上述示例中，不需要编写任何查询代码。可以自动获取每个客户的正确产品。尽管这个简单的例子不重要，但是当创建信息的网络时(具有诸如城市、州和国家的其地理空间信息的客户；具有在子类和超类中的其分类的产品)，链接数据的实际功能就会发挥作用。现在，系统可以自动回答查找特定位置与产品类别的连接的更复杂的查询和分析。对该查询的开发工作被省略。通过遍历信息的网络和查找匹配(也称为数据图遍历)进行执行语义查询。

语义搜索试图通过理解搜索者意图和术语当它们出现在可搜索数据空间中时(无论是在Web上还是在封闭系统内)的上下文含义来提高搜索准确性，以产生更相关的结果。语义搜索系统考虑各种各样的点，包括搜索的上下文、位置、意图以及词的变化、同义词、一般化和专业化查询、概念匹配和自然语言查询，以提供相关搜索结果。诸如Google和Bing的主要的web搜索引擎包含语义搜索的一些元素。语义搜索使用语义或语言中的意义的科学来产生高度相关的搜索结果。在大多数情况下，目标是传递用户查询的信息，而不是让用户对松散关联的关键字结果列表进行排序。例如，可以使用语义来增强在分级关系数据库中的记录搜索或查询。

语义查询允许关联和上下文性质的查询和分析。语义查询使得能够基于数据中包含的语法、语义和结构信息来检索显式导出信息和隐式导出信息。它们旨在提供精确的结果(可能是对单一信息的独特选择)，或者通过模式匹配和数字推理来回答更多模糊和广泛开放的问题。

语义查询作用于命名图、链接数据或三元组。这使查询能够处理信息之间的实际关系，并从数据的网络推断出答案。这与语义搜索相反，语义搜索使用非结构化文本中的语义(意义科学)来产生更好的搜索结果(例如，自然语言处理)。

从技术角度来看，语义查询是精确的关系型操作，很像数据库查询。它们作用于结构化数据，并且因此有可能利用诸如运算符(例如，>、<和＝)、名称空间、模式匹配、子分类、传递关系、语义规则和上下文全文搜索的综合特征。W3C的语义web技术堆栈提供SPARQL以类似于SQL的语法来形成语义查询。语义查询用在三元组存储器、图数据库、语义维基、自然语言和人工智能系统中。

语义查询的另一方面是关系的类型可以用于将智能并入系统中。在客户与产品之间的关系具有与邻居与其城市之间的关系根本不同的性质。后者使得语义查询引擎能够推断生活在曼哈顿的客户也生活在纽约市，而其他关系可能具有更复杂的模式和“情境分析”。这个过程被称为推理或推断，是软件基于给定事实导出新信息的能力。

语义物联网(IoT)

在我们的世界中部署的联网设备和传感器的数量的快速增加正在改变信息通信网络以及各个领域中的服务或应用。据预测，在未来10年内，数十亿台设备将为各种领域(如智能电网、智能家居、医疗保健、汽车、运输、物流和环境监测)中的许多应用和服务生成大量现实世界的数据。物联网(IoT)使得能够将现实世界的数据和服务整合到当前的信息网络中。

来自各种物理、网络和社会资源的数据的整合使得能够开发可以将情形和情境感知并入决策机制内并且可以创建更智能的应用和增强型服务的应用和服务。在处理大量分布式和异构物联网数据时，与互操作性、自动化和数据分析相关的问题与通用描述和数据表示框架以及机器可读和机器可解释的数据描述一起使用。将语义技术应用于物联网促进各种资源和数据提供者与消费者之间的互操作性，并促进有效的数据访问和整合、资源发现、语义推理和知识提取。语义注释可以应用于物联网中的各种资源。在语义网中开发的技术套件(如本体、语义注释、关联数据和语义Web服务)可用作实现物联网的主要方案。

然而，基于IoT的常规配置存在若干挑战，这些挑战需要考虑特殊的设计考虑以有效地将语义技术应用于现实世界数据。挑战可能包括动态性和复杂性、可扩展性、分布式数据存储和查询、数据的质量/信任/可靠性、安全性和隐私性或数据的解释和感知。在动态性和复杂性方面，现实世界的数据更为短暂，主要依赖于时间和地点。底层环境的普遍性和波动性需要不断更新和监控描述。关于可扩展性，物联网数据是指现实世界中的不同现象；所以带有数据的语义描述和注释需要与现实世界资源和实体的领域知识相关联，以便可以扩展到不同的和动态的实际情况。关于分布式数据存储/查询，对于大量数据和语义描述，存储效率和数据处理机制成为一个重大挑战，特别是考虑到涉及的规模和动态。关于数据的质量、信任和可靠性，IoT数据由不同的传感设备提供，这提供了对IoT数据中的不准确性和不同质量的关注。关于安全和隐私，物联网数据通常是个人的。提供和保证数据安全和隐私的机制可能是物联网中的重要问题。最后，关于数据的解释和感知，以机器可读和可解释格式提供的语义描述和背景知识支持将由机器和人类传感器创建的大量原始观察转换为对人类或自动化决策过程有意义的更高级抽象。然而，物联网中的机器感知为常规AI方法过去一直试图解决的问题增加了额外的挑战，例如来自不同源的数据的整合和融合、描述对象和事件、数据聚合和融合规则、定义阈值、大规模实时处理数据流以及质量和动态问题。

oneM2M架构

正在开发中的oneM2M标准(参见通过引用整体并入的oneM2M-TS-0001oneM2MFunctional Architecture-V2.3.0)定义了称为“公共服务实体(CSE)”的服务层。服务层的目的是提供可供不同“垂直”M2M系统和应用使用的“水平”服务。

如图3所示，CSE支持四个参考点。Mca参考点与应用实体(AE)连接。Mcc参考点与同一服务提供商域中的另一个CSE连接，Mcc参考点与不同的服务提供商域中的另一个CSE连接。Mcn参考点与底层网络服务实体(NSE)连接。NSE为CSE提供底层网络服务，如设备管理、位置服务和设备触发。

CSE包含称为“公共服务功能(CSF)”的多个逻辑功能，诸如“发现”、“数据管理和存储库”。图4图示了在oneM2M正在开发的CSF。

oneM2M架构实现了如图3所示的以下类型的节点：应用服务节点(ASN)、应用专用节点(ADN)、中间节点(MN)、基础设施节点(IN)和非oneM2M节点(NoDN)。ASN是包含一个CSE并且至少包含一个应用实体(AE)的节点。例如，关于物理映射，ASN可以驻留在M2M设备中。ADN是包含至少一个AE并且不包含CSE的节点。oneM2M系统的场域中可能有零个或更多个ADN。例如，关于物理映射，ADN可以驻留在受约束的M2M设备中。MN是包含一个CSE并包含零个或更多AE的节点。oneM2M系统的场域中可能有零个或更多个MN。例如，关于物理映射，MN可以驻留在M2M网关中。IN是包含一个CSE并包含零个或更多个AE的节点。每个oneM2M服务提供商在基础架构域中都有一个IN。IN中的CSE可能包含不适用于其他节点类型的CSE功能。例如，关于物理映射，IN可以驻留在M2M服务基础架构中。非oneM2M节点是不包含oneM2M实体(既不是AE也不是CSE)的节点。这些节点代表连接到oneM2M系统的设备，用于互通目的，包括管理。

在图5中示出了互连在oneM2M系统内支持的各种实体的可能配置。

oneM2M架构中的语义描述

<semanticDescriptor>资源用于存储关于资源和可能的子资源的语义描述。可以根据本体来提供这样的描述。语义信息由oneM2M系统的语义功能使用，并且也可用于应用或CSE。

通常，<semanticDescriptor>资源应包含表1中指定的属性。图6图示了在资源树中的<semanticDescriptor>资源的结构。

表1：<semanticDescriptor>资源的属性

oneM2M中的语义过滤建议

通过具有在请求操作中指定的过滤标准来支持一般过滤(oneM2M-TS-0001oneM2MFunctional Architecture-V2.3.0第8.1.2节)。为了提供语义过滤，已经提出了用于请求操作过滤标准的附加值，其定义如下表2所示。可以使用多个实例，这根据用于评估过滤标准的一般规则意味着“OR”语义适用，例如，如果一个或多个语义过滤器匹配语义描述，则语义过滤标准的总体结果为真。

表2.语义过滤标准

上述建议使用以下假设：语义描述被指定为RDF三元组(尚未在oneM2M中完全指定诸如RDF/XML、Turtle、描述格式的表示)；语义过滤标准将用于要在语义描述上执行的SPARQL请求

在一些情况下，单个搜索的相关语义信息可以分布在不同的<semanticDescriptor>资源中。在图7中提供的示例说明了这种情况。显示代表主语-谓语-宾语关系的语义图，该图的不同部分(由椭圆表示)被存储在不同的<semanticDescriptor>资源中。语义过滤需要应用于完整语义图(的部分)，这就产生了图的几个不同部分必须放在一起以执行语义操作的问题。

这个问题在语义web的领域中通常不明显，因为可以直接对标识类实例的URI进行取消引用，从而可以基于其URI找到概念(例如，类、关系)信息。在oneM2M情况下，只有可以访问的资源以及语义被存储为资源内容。由于在这种情况下，语义实例不是一等公民，所以基于URI的方法在oneM2M情况下不适用。

常规的SPARQL 1.1支持使用SERVICE关键字的联合查询，其中，可以指定远程SPARQL端点的URL。对于这种方法，请求者会先验地知道哪些语义描述符包含搜索所需的语义实例，使得当语义描述符分布在资源树中时这种方法通常不适用。

如在oneM2M中所呈现的，对跨<semanticDescriptor>资源存储的语义描述启用语义过滤的解决方案以resourceDescriptorLink OWL注释属性的形式引入注释链接。可以为任何类实例指定此注释属性，其值是<semanticDescriptor>资源的URL，其中，可以找到用于给定类实例的其他RDF三元组。以下示例使用在oneM2M基础本体中定义的类和关系(图8)以便创建图9中的图。

该解决方案需要在接收者处的基于SPARQL的语义过滤引擎的以下功能流程。首先，对候选资源的语义描述符资源的内容执行构造为SPARQL请求的语义过滤器。其次，如果在执行过程中遇到包含一个或多个resourceDescriptorLink注释的类实例，则会停止执行。第三，resourceDescriptorLink引用的每个<semanticDescriptor>资源的内容被添加到正在执行SPARQL请求的内容(懒惰评估、替代方法：在执行前获取所有内容，但可能导致获取不必要的信息)。第四，对扩大的内容继续执行SPARQL请求。

oneM2M中的访问控制策略

如图10所示，常规的<accessControlPolicy>资源由特权(privileges)和selfPrivileges属性组成，该属性表示一组访问控制规则，它们定义哪些实体(由accessControlOriginators定义)有权在指定的上下文(由accessControlContexts定义)中执行某些操作(由accessControlOperations定义)，并由CSE用于对特定资源进行访问决策。在特权中，每个访问控制规则定义哪个AE/CSE被允许用于哪个操作。因此，对于访问控制规则集，如果集合中的一个或多个访问控制规则允许，则允许操作。对于不是<accessControlPolicy>资源类型的资源，此类资源的公共属性accessControlPolicyIDs包含将该资源链接到<accessControlPolicy>资源的标识符列表。这种资源的CSE访问决策应遵循由<accessControlPolicy>资源中定义的特权属性表示的访问控制规则集的评估。selfPrivileges属性应表示用于<accessControlPolicy>资源本身的访问控制规则集。<accessControlPolicy>资源的CSE访问决策应遵循由<accessControlPolicy>资源本身中定义的selfPrivileges属性表示的访问控制规则集的评估。

<accessControlPolicy>资源通常包含表3中指定的属性。

表3：<accessControlPolicy>资源的属性

在特权和selfPrivileges属性中表示的常规访问控制规则集由以下描述的三元组构成。accessControlOriginators是访问控制规则元组中的一个参数。它表示允许使用此访问控制规则的一组始发者。这组始发者被描述为参数列表，其中，参数的类型可以在列表内变化。表4描述了accessControlOriginators中的支持的参数类型。

表4：accessControlOriginators中的参数类型

当originatorID是包含<AE>或<remoteCSE>作为成员的<group>资源的资源ID时，资源的托管CSE确定请求的始发者是否匹配<group>资源的memberID属性中的成员之一(例如，通过检索<group>资源)。如果<group>资源不能被检索或不存在，则该请求将被拒绝。

accessControlContexts是包含列表的访问控制规则元组中的参数，其中，列表中的每个元素当存在时表示允许使用该访问控制规则的上下文。每个请求上下文都由一组参数来描述，其中，参数的类型可以在该集内变化。表5描述了accessControlContexts中的支持的参数类型。CSE应考虑以下常规Originator accessControlContexts用于访问控制策略检查。

表5：accessControlContexts中的参数类型

accessControlOperations是访问控制规则元组中的参数，其表示使用此访问控制规则授权的一组操作。表6描述了accessControlOperations授权的支持的一组操作。以下accessControlOperations应被CSE考虑用于访问控制策略检查。

表6：accessControlOperations中的参数类型

名称	描述
		RETRIEVE	用于检索寻址资源的内容的特权
CREATE	用于创建子资源的特权
		UPDATE	用于更新寻址资源内容的特权
DELETE	用于删除寻址资源的特权
		DISCOVER	用于发现资源的特权
NOTIFY	用于接收通知的特权

M2M语义支持的建议功能架构

图11示出了用于M2M语义支持的建议功能架构，主要组件可以包括资源存储库、本体处理器、本体存储库、语义存储库、规则存储库、推理器(reasoner)或语义查询处理器。资源存储库存储从物理M2M设备收集的所有资源。M2M语义支持旨在使语义能够用于原始资源以获得它们的通用理解/解释以及对于它们的任何高级处理，例如，语义查询、数据分析等。本体处理器负责处理、分类、存储并提供M2M域的外部和内部的发布/生成的本体的发现功能。本体存储库存储本体。这些本体可以用来为资源启用语义。语义存储库将注释的语义信息存储在某些表示中，这些表示可能有利用RDF的选项。语义注释是以具体格式(例如二进制流)表示资源语义的过程。规则存储库存储用于表示新知识的规则，这些新知识经常超出与资源存储库中的资源相关联的现有语义。规则通常是条件语句：if-then子句。推理器从规则存储库和语义存储库中现有的资源语义信息中获取输入，并在满足规则中的条件时生成新的资源语义信息。新的资源语义信息被添加到语义存储库中。语义查询处理器处理来自客户端的查询，以搜索存储在语义存储库中的资源语义信息并将结果返回给客户端。

发明内容

本文公开了为集中式语义图存储提供对RESTful操作的访问控制并且提供对分布在资源树数据库中的语义RDF三元组的操作的方式。

在一个示例中，在集中式语义图存储中可以存在语义描述符。本文提供了关于下述部分的细节：具有在集中式语义图存储中的语义描述符的架构、具有在集中式语义图存储中的语义三元组或图的restful操作、具有由访问控制策略指定的访问控制规则的用于集中式语义图存储的访问控制和具有语义查询的资源发现等等。

在另一个例子中，分级资源树中可能存在语义描述符。本文提供了关于下述部分的细节：具有分布在分级资源树中的语义描述符的架构和具有分布在分级资源树和临时语义图存储中的语义描述符的语义查询等。

在另一个示例中，在集中式语义图存储和资源树中可以存在语义描述符。本文提供关于下述部分的细节：具有在集中式语义图存储和资源树中的语义描述符的架构以及具有在集中式语义图存储和资源树中语义描述符的语义查询。

公开了使用在分级资源树机制中分布的语义描述符来维护语义描述符关系信息的架构。这些机制使得能够通过一起使用特定的语义描述符集来在特定图的上下文中执行语义查询。为了语义操作目的而使用组的形成的机制还使得能够使用组资源以便向组的成员扇出语义请求，该成员包括位于不同服务实体上的成员。

使能的附加功能包括通过以集中方式维护与整个组相关联的复合图来进行查询优化。当使用组方法时，本地三元组存储的存储、缓存等可以进一步优化查询处理。通过将组与图命名规则结合使用，功能还包括以语义操作为目标并使其具体化或尽可能广泛的更大粒度。

提供本发明内容是为了以简化的形式介绍将在以下具体实施方式中进一步描述的概念的选择。本发明内容并非旨在识别所要求保护的主题的关键特征或基本特征，也并非旨在用于限制所要求保护的主题的范围。所要求保护的主题不限于解决本公开的任何部分中指出的任何或全部缺点的限制。

附图说明

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

图2示出了示例性的分级数据库；

图3示出了示例性的oneM2M架构；

图4示出了示例性的oneM2M公共服务功能；

图5示出了由oneM2M架构支持的示例性配置；

图6示出了资源树中的<semanticDescriptor>资源的示例性结构；

图7示出跨越存储在不同资源中的语义信息的语义过滤器的示例性范围；

图8示出了示例性的oneM2M基本本体；

图9示出了示例性resourceDescriptorLink；

图10示出了<accessControlPolicy>资源的示例性结构；

图11示出了M2M语义支持的示例性功能架构；

图12示出了集中式语义图存储中的示例性语义描述符；

图13示出了分布在分级资源树中的示例性语义描述符；

图14A示出了集中式语义图存储中的语义描述符的示例性架构；

图14B示出了多个语义图存储中的语义描述符的示例性架构；

图15示出了两个语义三元组之间的示例性链接；

图16示出了用于集中式语义图存储的示例性一般操作流程；

图17示出了具有过渡(Transit)SE的集中式语义图存储的示例性一般操作流程；

图18示出了用于CREATE语义三元组的示例性操作流程；

图19示出了用于RETRIEVE语义三元组-语义查询的示例性操作流程。

图20示出了用于UPDATE语义三元组的示例性操作流程；

图21示出了用于DELETE语义三元组的示例性操作流程；

图22示出了在语义图存储中使用<AccessControlTriples>用于访问控制的示例；

图23示出了示例性eHealth本体论参考模型；

图24示出了示例性访问控制本体模型；

图25示出了在语义图存储中的示例性eHealth三元组；

图26示出了具有访问控制的示例性eHealth语义查询；

图27示出了在分级资源树中分布的语义描述符的示例性架构；

图28示出了资源树中的具有分布式语义描述符的示例性语义查询。

图29示出了语义图存储和分级资源树中的语义描述符的示例性架构；

图30示出了用于具有在资源树中的语义描述符和在语义图存储中的语义三元组的语义查询的示例性方法；

图31示出了相同描述符之间的多个resourceDescriptionLinks的示例性问题；

图32示出了示例性relatedSemantics属性；

图33示出了分布在不同语义描述符上的示例性图。

图34示出了来自分布在分开的描述符中的子图的示例性复合图；

图35示出了具有链接列表的示例性使用或relatedSemantics属性；

图36示出了示例性<semanticGroup>资源；

图37示出了具有<semanticGroup>的示例性使用或relatedSemantics属性；

图38示出了图31中表示的合成图的示例性RDF描述。

图39示出了<Device12>(<设备12>)的semanticDescriptor描述符属性的示例性内容；

图40示出了当使用链接列表方法时的示例性relatedSemantics属性；

图41示出了当使用链接组方法时的示例性semanticGroupLinks属性。

图42示出了在基于任意图的方案中的<Device12>的示例性语义注释。

图43示出了在基于任意图的方案中的示例性<OperationA>(<操作A>)注释；

图44示出了使用链接组方法时的示例性semanticGroupLinks属性。

图45示出了使用RelatedSemantics链接方法的示例性语义查询；

图46示出了示例性的增强型<semanticGroup>资源；

图47示出了使用oneM2M的公开方法的示例性架构；

图48示出了使用oneM2M的公开方法的示例性资源树；

图49A示出了语义图存储中的示例性视图；

图49B示出了了与语义图存储相关联的示例性方法；

图49C示出了与语义图存储相关联的访问控制的示例性方法；

图50示出了可以基于这里的方法和系统生成的示例性显示；

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

图51B是可以在图51A中所示的M2M/IoT通信系统内使用的示例架构的系统图；

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

图51D是其中图51A的通信系统的各方面的可以被具体化的示例计算系统的框图；

图52图示了语义图存储中的访问控制策略的示例；

图53A示出了具有访问控制的eHealth语义查询的示例1；

图53B示出了具有访问控制的eHealth语义查询的示例2；

图53C示出了具有访问控制的eHealth语义查询的示例3；以及

图54图示了用于经由语义查询来执行资源发现的示例性方法。

具体实施方式

如本文关于“语义物联网”所描述的，当与语义web相比时，对于语义IoT存在许多挑战。第一个挑战是安全和隐私，尤其是作为与图12相关联的用例I中所示的情形——应该解决如何控制对集中式语义图存储的访问以及如何有效地管理语义图存储的访问控制策略。另一个挑战是在RDF三元组中分布在数据库中的大量语义描述符，或者不作为与图13相关联的用例II中所示的情形——应该解决如何从分级资源树中提取语义RDF三元组并对RDF三元组进行操作。关于用例II中的分布式语义描述符，另一个与查询有关的问题是查询的范围，其可以被看作搜索图的范围或由描述符产生的相应的RDF描述的范围。此搜索与用作查询操作目标的资源相关联，但默认范围很容易导致未优化的搜索

这里公开了被应用到用于语义物联网服务或应用的语义描述符的RESTful操作的多种方法。本文提供了集中式语义图存储中的语义描述符的机制的细节、在分级资源树中分布的语义描述符的机制以及用于位于集中式图存储和分级资源树两者中的语义描述符的混合机制。还讨论了分布在服务实体内的语义描述符的替代方案。这里应该理解，术语“图”的使用可以与“语义图”等等互换。

考虑图12讨论用例I。如图12所示，以RDF三元组(例如，语义描述符)的形式的语义描述被存储在集中式RDF三元组数据库(例如，语义图存储)处。例如，医生D和医生D的患者A和B将他们的语义描述符存储到集中式RDF三元组存储或语义图存储中，然后如果患者授权给医生D，则医生D可以对其所有患者的语义描述符进行语义查询，并且如果医生D向他的患者授权，则患者也可以对他们自己的语义描述符和一些医生D的语义描述符进行语义查询。但是，如果没有授权，则患者不能对彼此的语义描述符进行语义查询。此外，如果是由医生D的患者授权的，则医生D可以更新或删除他的语义描述符以及可能是他的一些患者的语义描述符，并且类似地，如果医生D授权，则患者可以更新或删除他或她自己的语义描述符以及可能是医生D的语义描述符的一些。

考虑图13讨论用例II。如图13所示，RDF三元组(例如，语义描述符)的形式的数据和语义描述都存储在关系数据库(例如，分级资源树)中。例如，医生D和医生D的患者A和B将他们的数据和语义描述符存储到关系数据库或分级资源树中。语义描述符1描述与相关的eHealth应用相关的语义信息，语义描述符2用于数据容器，而语义描述符3用于特定的数据实例。之后，如果患者授权给医生D，则医生D可以对在资源树中他的所有患者的语义描述符使用语义描述或语义查询来进行语义搜索，如果医生D向资源树中的患者授权，则患者可以使用语义描述或语义查询对他们自己的语义描述符和医生D的语义描述符的一些进行语义进行搜索。但是，如果没有授权，则患者不能对彼此的语义描述符进行语义查询。此外，如果是由医生D的患者授权的，则患者可以更新或删除他的语义描述符和可能是他的患者的语义描述符的一些，并且，如果是由医生D授权的，则患者可以更新或删除他或她自己的语义描述符和可能是医生D的语义描述符的一些。

以下公开了一些一般考虑事项。语义描述可以具有RDF三元组之类的格式或可以不具有RDF三元组之类的格式。一般格式的语义描述(例如，非专门的RDF三元组之类的S-P-O关系描述)与其他资源相同，例如资源树中的元数据或上下文信息。这里，围绕诸如RDF三元组S-P-O的关系中的语义描述进行讨论，因此术语语义描述符或语义三元组用于RDF三元组之类格式的语义描述。SPARQL用于RDF三元组仅用于说明目的。这些解决方案对于其他类型的语义表达和用于链接数据的语义查询语言是通用的。数据是在此用于资源树中的记录的一般术语，其可以是数据样本或上下文信息(例如，元数据)。可通过语义三元组语句中的唯一标识符(例如，国际化资源标识符(IRI)或统一资源标识符(URI))来寻址语义三元组(例如，三元组S-P-O的S、P或O)中的元素或节点。URI被使用，但是IRI或其他标识符(例如，URL)也适用于所公开的机制中。RDF三元组S-P-O中的元素或节点可以通过URI、空白节点标签或Unicode字符串文字表示。为了简化语句，在语义三元组的某些示例中不使用基本或名称空间。语义三元组用于RESTful操作讨论，但这些机制也可适用于例如由SPARQL Update1.1支持的语义图(例如，链接的三元组或链接的数据)操作。应该理解的是，这里考虑，一个部分或示例的操作可以被应用于另一个部分或示例。例如，本文公开的关于用于集中式架构的集中式语义图存储的restful操作的操作消息(例如，请求和响应)也适用于用于本文公开的其他架构的操作，例如分布式资源树中分布的语义描述符以及语义图存储和分级资源树中的语义描述符。

如图14A所示(参见用于下面图14A和14B讨论的附加上下文的用例I和II以及图29)，集中式架构具有以下特征。语义图存储可以驻留在服务实体(SE)(例如，oneM2M中的CSE)上，并且包含经由其单独的URI指向不同资源树中的不同资源的语义三元组。如果URI在物联网系统中可达或可访问，则URI与URL相同。由语义三元组经由URI(在图14B中所示)寻址或指向的资源可以位于服务实体上的同一分级资源树上，例如，所有医生D的资源被存储在SE 1上的资源树1处，或者由语义三元组经由URI(如在图14B中所示)寻址或指向的资源可以位于多个服务实体上的不同分级资源树处，例如，患者A的资源位于SE2的资源树2处，患者B的资源位于SE3上的资源树3处，但相应的语义三元组位于SE1处。应用实体(AE)(例如，oneM2M中的AE)可以通过接口AS(例如，oneM2M中的Mca接口)与服务实体进行通信，以用于对于在资源树中的资源或在语义图存储中的语义三元组的RESTful操作，例如CREATE、RETRIEVE、UPDATE、DELETE等。服务实体(SE)可以通过接口SS(例如，在oneM2M中的Mcc或Mcc’接口)与另一个服务实体(SE)进行通信，以用于对于在资源树中的资源或在语义图存储中的语义三元组的RESTful操作，例如CREATE、RETRIEVE、UPDATE、DELETE等。数据存储管理器负责与其他外部实体(例如，AE和/或SE)以及内部实体(例如，语义存储管理器和/或其他常用功能实体)的数据交换；通过用于CREATE、RETRIEVE、UPDATE、DELETE等的命令的资源树数据库操作和管理。语义存储管理器负责：与其他外部实体(例如，AE和/或SE)以及内部实体(例如，数据存储管理器)和/或其他常用功能实体的语义三元组交换；或通过用于CREATE、RETRIEVE、UPDATE、DELETE等的命令的语义图存储操作和管理。

在图14A中示出，医生D的三元组和数据位于同一个SE上，但也可能它们位于不同的SE处。另外有可能的是，图14A中所示的集中式语义图存储位于处于另一个服务域(例如，另一个服务提供者)中的SE处。在这种情况下，RESTful操作例如通过oneM2M中的接口Mcc'跨越服务域。

在图14B中示例了在物联网系统中具有多个集中式语义图存储的另一种架构。在这种架构中，语义图存储1位于SE1处，语义图存储2位于SE2处。语义图存储1和语义图存储2之间的操作可以通过用于CREATE、RETRIEVE、UPDATE、DELETE等的命令在接口SS1(例如，在oneM2M中的Mcc/Mcc'接口)处进行。

如图14A中示例，三元组在语义图存储中被连接或链接。例如，如图15所示，三元组1“医生D具有患者A”通过PatientA_URI与三元组2“患者A具有心脏数据X”链接。

诸如<Doctor D>的资源被存储在资源树1中的Doctor_URI上，并且诸如<PatientA>和<Heart-Data X>(图14A中未示出)的资源被分别存储在资源树2中的PatientA_URI和HeartData_URI(图14A中未示出)处。

医生D的eHealth应用(例如，应用实体1)可以经由接口AS1与服务实体1进行通信，以分别经由接口AS1对于在服务实体1处的资源树1中、经由接口SS1通过服务实体1对于在服务实体2处的资源树2中和经由接口SS2通过服务实体1对于在服务实体3处的资源树3中的他或他的患者的资源(如果被授权)进行RESFTful操作。医生D的eHealth应用也可以通过接口AS1对于在服务实体1处的语义图存储中的他或她的患者的语义三元组(如果被授权)应用RESTful操作。

患者A的心脏监测器eHealth应用(例如，应用实体2)可以经由接口AS2与服务实体2通信，以分别通过接口AS2对于在服务实体2处的资源树2中和通过接口SS1通过服务实体2对于在服务实体1处的资源树1中的他或医生D的资源(如果被授权)进行RESFTful操作。患者A的心脏监测器eHealth应用也可以经由接口SS1通过服务实体2对于在服务实体1处的语义图存储中的他或医生D的语义三元组(如果被授权)应用RESTful操作。

应该理解的是，执行图16-图21和类似的附图中所示的步骤的实体是可以以软件(例如，计算机可执行指令)的形式实现的逻辑实体，该软件存储在诸如在图51C或图51D中所示的那些的设备、服务器或计算机系统的存储器中，并且在该设备、服务器或计算机系统的处理器上执行。也就是说，图16-图22、图27-图30、图45-图49和类似的附图中所示的一个或多个方法可以以存储在计算设备的存储器中的软件(例如，计算机可执行指令)的形式来实现，所述计算设备例如是图51C或图51D所示的设备或计算机系统，该计算机可执行指令在由计算设备的处理器执行时执行图16-图22、图27-如图30、图45-图49和类似的附图中所示的步骤。在一个示例中，下面使用关于M2M设备的交互的进一步细节，图29的AE 373可以驻留在图51A的M2M终端设备18上，而图29的SE 361可以驻留在图51A的M2M网关设备14上。

图16示出了用于图14A中所示的架构的示例性通用RESTful语义三元组操作流程(例如，医生D的eHealth应用AE1请求对语义图存储中的三元组的语义三元组或图操作)。图17示出了用于图14A中所示的架构的示例性一般RESTful语义三元组操作流程(例如，患者A的心脏监测器eHealth应用AE2请求对语义图存储中的三元组的语义三元组或图操作)。图16和图17可基于AE和SE之间经由AS接口(例如，oneM2M中的Mca接口)的RESTful请求和响应消息或经由SS接口(例如，oneM2M中的Mcc或Mcc'接口)的SE之间的RESTful请求和响应消息。这里描述的示例机制也适用于用于图14B中示出的架构的语义图操作，例如SE1处的语义图存储1与SE2处的语义图存储2之间的图操作。请求消息可以包含基于不同语义三元组或图操作的强制性的操作相关或可选参数。请求消息可以包含以下参数，这些参数是示例，并不一定是选项或强制性的等。这依赖于实现。

继续参考一般的RESTful语义三元组操作流(例如，图16和图17)，第一组参数可以包括与对资源发现的尝试相关的以下内容。“To”字段可以包括<SemanticGraphStore>资源的地址或ID。可以通过预供应或通过资源发现来知道<SemanticGraphStore>资源。“From”字段可以包括始发者151的ID(例如，AE ID或SE ID)。接收者152(例如，SE)可以使用这个来检查始发者对语义图存储中的语义三元组操作的访问特权。操作字段可以包括要进行的操作，诸如CREATE(C)、RETRIEVE(R)、UPDATE(U)、DELETE(D)等。操作类型可以包括可以是资源树中的用于资源操作的“资源”、语义图存储中的用于三元组操作的“三元组”和/或语义图存储中的用于图操作的“图”的值。默认值是“资源”。这里给出的许多例子都是关于三元组和图操作的。请求标识符可以包括要用于在请求和响应之间的关联的请求标识符。

继续参考一般的RESTful语义三元组操作流(例如，图16和图17)，可以将第二组参数视为用于三元组或图操作的操作相关参数。可能会有如下面更详细讨论的内容和内容格式。内容可以包括要传送的语义内容(例如，三元组或图)，其可以根据语义三元组或图操作而不同地呈现。在一个示例中，关于CREATE，内容可以是<Operation Type>为“triple(三元组)”或“graph(图)”的新语义三元组的内容。例如，诸如“Doctor-D_URI具有PatientA_URI”的三元组。在一个示例中，关于UPDATE，内容可以包括将被现有语义三元组或图替换的内容。例如，“Doctor-D_URI具有PatientA_URI2”以替代用于图15所示的三元组110的“Doctor-D_URI具有PatientA_URI1”。要被更新或替换的现有语义三元组或图可以由<SemanticTripleGraphID>(例如，图的唯一名称)显式地寻址，或由语义查询引擎通过使用这个新内容来推断以匹配在语义图存储中的三元组或图关系网络。在一个示例中，关于RETRIEVE，内容可以包括查询语义三元组。例如，“？医生有患者A”(？医生是查询的变量)用于查询患者A的医生。在一个示例中，关于DELETE，内容可以包括要删除的现有语义三元组或图的内容。现有的语义三元组或图可以由<SemanticTripleGraphID>(例如，图的唯一名称)明显地寻址以用于删除，或被语义查询引擎通过使用该内容推断来匹配语义图存储中的三元组或图。

参照如上所述的内容格式，内容格式可以被认为是语义三元组或图形操作内容的格式，例如：用于三元组的N-Triple、JSON、RDF/XML或Turtle；用于查询的SPARQL；或其他结构化文本或文字。

继续参考一般的RESTful语义三元组操作流程(例如，图16和图17)，可以考虑第三组参数。可以存在creator(创建者)参数，其中，它指示要传送的语义内容的创建者，例如AEID或SE ID。可能存在Semantic Triple Graph IDs(语义三元组图ID)参数，其中，它如果未被始发者151呈现或与在语义图存储中的现有三元组冲突则可以由接收者152创建。Semantic Triple Graph IDs参数是语义三元组图的ID，并且可以是绝对的或相对的但是在语义图存储中唯一的。可以存在Access Control Policy IDs(访问控制策略ID)参数，其中，接收者152可基于始发者151的ID和服务简档来创建(如果未由始发者151呈现)。接收者152可使用该参数来检查始发者的访问控制特权，并相应地验证所述操作。可能存在Ontology Ref参数，其中，接收者152可以基于始发者151的ID和服务简档创建<OntologyRef>(如果未由始发者152呈现)。

继续参考第三组参数，可以存在response message type(响应消息类型)参数、result content(结果内容)参数或filter criteria(过滤标准)参数。response messagetype参数可以指示可以向发出的请求发送什么类型的响应以及何时可以将响应发送到始发者151。始发者151可以基于通信、三元组操作等待时间、系统能力、当前处理或加载状态等请求不同的响应类型。响应消息类型可以包括以下内容：ACK同步、ACK异步、NoACK同步或ACKnoACK等等。对于ACK同步，在接受之后，接收者152可以用确认接收者152将进一步处理该请求的确认进行响应。执行所请求的操作的成功或失败将在稍后传达。对于ACK异步{通知目标列表}，在接受之后，接收者152可以用确认接收者将进一步处理该请求的确认进行响应。请求的操作的结果应作为通知发送给通知目标。通知目标可以在该参数内被提供为实体列表或当没有提供通知目标列表时被提供给始发者151。当由始发者151提供空的通知目标列表时，可以根本不发送带有所请求的操作的结果的通知。对于NoACK同步，在接受之后，接收者152可以在完成所请求的操作之后以所请求的操作的结果进行响应。这可能是响应类型参数未被给出请求时的默认行为。对于ACKnoACK{通知目标列表}，在接受之后，接收者152可以使用上述的ACK或NoACK来确定如何基于其状态或其他服务策略进行响应。

可以存在result content(结果内容)参数，其中，结果内容指示所请求的操作的结果的预期分量。语义三元组图ID：请求语义三元组的<SemanticTripleGraphIDs>。语义三元组或图是作为内容返回的所请求的语义三元组或图的表示。语义三元组节点可以是URI、银行网点标签或用于请求语义三元组的三元组节点的“文字”。如果返回URI，这可以由<URIType>指示。URI类型表示绝对或相对URI。如果使用相对URI，则<NameSpace>或本体引用可以包含在相对URI中。True/False：请求操作的布尔逻辑结果，例如，用于SPARQL Query“ASK”操作。

可以存在filter criteria(过滤器标准)参数，其指示用于在语义图存储中的过滤的语义三元组或图操作的过滤标准。下面显示了用于SPARQL查询的过滤的示例。

以下列出SPARQL内置过滤功能。

o逻辑：！、&&、||

o数学：+、-、*、/

o比较：＝、！＝、>、<、...

o SPARQL测试：isURI、isBlank、isLiteral、bound

o SPARQL访问器：str、lang、数据类型

o其他：sameTerm、langMatches、正则表达式

响应消息可以包含基于不同语义三元组操作的所有类型的参数。可以以不同的方式提供参数，但下面是示例。根据实施，一些参数可以是或者可以不是可选的或被认为是强制的。示例性参数如下。第一组参数可以包括响应状态或请求标识符。响应状态可以指示所请求的操作的结果是成功的、不成功的、确认(例如，稍后要传送的结果)或诸如授权超时等的处理的状态。请求标识符(ID)参数可以标识相应的请求。

可以被认为是与操作有关的第二组参数可以包括以下示例：内容或内容状态。内容可能包括响应内容，例如，如果响应状态成功，则：1)CREATE-内容是语义图存储中的<SemanticTripleGraphIDs>；2)UPDATE-内容是在语义图存储中替换的语义三元组或图；3)DELETE-内容是删除的语义三元组或图；或4)RETRIEVE-内容是可以包含<SemanticTripleGraphIDs>、<SemanticTriples/Graph>、<SemanticTripleNodes>或<True/False>布尔逻辑结果的语义查询结果，如请求消息中的<ResultContent>所示。如果响应状态不成功，则响应中的内容参数可能包含错误信息。如果响应状态是确认，则如果如请求中指定那样<ResponseType>是基于ACK的，则内容参数可以包含<SemanticTripleGraphID>。如果响应状态成功，则内容状态参数可以在对于检索操作的响应中指示何时对语义查询返回的内容是部分的。

第三组参数可以是以下示例：“To”或“From”。“to”参数可以指示始发者151或中转SE 150的地址或ID。“from”参数可以指示接收者152的ID。

在以下附图中以“triple(三元组)”示出了一些前述操作的一些额外细节。图18提供了CREATE语义三元组的操作流程。图19提供用于RETRIEVE语义三元组——语义查询——的操作流程。图20提供了用于UPDATE语义三元组的操作流程。图21提供用于DELETE语义三元组的操作流程。

在图18至图21中详细描述的机制也适用于用于语义图存储或在语义图存储之间的语义图操作。图18示出了用于CREATE语义三元组的示例性操作流程。在步骤201，发送语义三元组CREATE操作请求。步骤201的请求可以包括：1)To：SemanticGraphStore和From：始发者ID(例如，AE ID或SE ID)；2)操作：CREATE；3)参数：RequestID、ContentFormat(例如，RDF XML)、AccessControlPolicyIDs、OntologyRef、Creator、ResponseType、ResultContent(是SemanticTripleIDs)；以及4)Content：SemanticTriples。

继续参考图18，在步骤202，例如，在接收者152处发生语义三元组CREATE操作处理。在语义图存储154中可以存在对语义三元组CREATE操作的验证。验证可以包括以下内容。如果<AccessControlPolicyIDs>不存在，基于<ServiceSubscriptionPolicy>和其他服务策略确定始发者151是否具有创建由<AccessControlPolicyIDs>指定的目标语义三元组或者创建和分配<AccessControlPolicyIDs>的特权。如果始发者151没有提供<ontologyRef>的验证和<ontologyRef>的分配，则也可以存在<ontologyRef>的验证和<ontologyRef>的分配。另外，如果由始发者151在步骤201的CREATE请求中提供，则可以验证<SemanticTripleIDs>未存在于语义图存储154中。如果否，则可以使用由始发者151建议的<SemanticTripleIDs>，否则将唯一的<SemanticTripleIDs>用于要创建的语义三元组。而且，“AccessControlTriples”(例如，定义Who-What-How(谁-什么-如何)的访问控制规则元组)可以与基于要通过<privileges>在<AccessControlPolicy>下指定的访问控制策略规则创建的语义三元组相关联，其中，通过<AccessControlPolicyIDs>来标识<AccessControlPolicy>。如果<creator>被包括在步骤201的请求中，则“CreatorTriple”可以与要创建的语义三元组相关联。最后，在成功验证了步骤201的CREATE请求后，如果在步骤201的请求中没有提供，则创建语义三元组CREATE操作命令。例如，在SPARQL Update语言中在语义图存储154中“插入”三元组或“添加”图。

继续参考图18，在步骤203，在语义图存储154中进行语义CREATE操作。在图18中示出一个例子。例如，可以通过SPARQL 1.1Update来提供这些图管理操作，这些操作也可用于映射CREATE操作：1)CREATE：在支持空图的存储中创建新图；2)COPY：修改图以包含另一个图的副本；3)MOVE：将所有数据从一个图移动到另一个图；或4)ADD：将所有数据从一个图复制到另一个图。在步骤204，用CREATE操作结果编写响应。在步骤205，存在语义三元组CREATE操作响应。该响应可以包括1)To：始发者ID(例如，AE ID或SE ID)和From：接收者ID(例如，SE ID)；2)参数：RequestStatus(成功)，RequestID；以及3)内容：SemanticTripleIDs(如果ResponseType是NoACKsync)。

图19示出了用于RETRIEVE语义三元组-语义查询的示例性操作流程。在步骤211，发送语义三元组RETRIEVE操作请求。步骤211的请求可以包括1)To：SemanticGraphStore和From：始发者ID(例如AE ID或SE ID)；2)操作：RETRIEVE；3)参数：RequestID、ContentFormat(例如，SPARQL)、FilterCriteria或ResultContent；以及4)内容：SemanticTriples。

继续参考图19，在步骤212，例如，在接收者152处发生语义三元组RETRIEVE操作处理。在语义图存储154中可以存在对语义三元组RETRIEVE操作的验证。验证可以包括以下内容。基于与三元组相关联的<AccessControlPolicy>来确定始发者151(使用AE ID或SE ID)是否具有RETRIEVE(检索)由其查询语义三元组指定的语义三元组或其他信息的特权。如果需要，则也可以验证<ontologyRef>。另外，可能会确定FilterCriteria是否有效。最后，在成功验证步骤211的RETRIEVE请求时，可以创建语义查询命令。例如，在SPARQL查询语言中，“SELECT”用于结果值的表格，“CONSTRUCT”用于RDF图，“ASK”用于“真/假”布尔结果，或“DESCRIBE”用于语义图存储154返回的任何内容。

继续参考图19，在步骤213，在语义图存储154中进行语义查询操作。在图19中示出一个例子。在步骤214，用RETRIEVE操作结果编写响应。在步骤215，存在语义三元组RETRIEVE(检索)操作响应。该响应可以包括1)To：始发者ID(例如，AE ID或SE ID)和From：接收者ID(例如，SE ID)；2)参数：RequestStatus(成功)、RequestID；以及3)内容：SemanticTriples(如果ResponseType是NoACKsync)。

图20示出了用于UPDATE语义三元组的示例性操作流程。在步骤221，发送语义三元组UPDATE操作请求。步骤221的请求可以包括1)To：SemanticGraphStore和From：始发者ID(例如，AE ID或SE ID)；2)操作：UPDATE；3)参数：RequestID、SemanticTripleIDs、ContentFormat(例如，RDF XML)、FilterCriteria、ResultantContent；以及4)内容：SemanticTriples。

继续参考图20，例如，在步骤222，在接收者152处发生语义三元组UPDATE操作处理。在语义图存储154中可以存在对语义三元组UPDATE操作的验证。验证可以包括以下内容。确定始发者151是否具有UPDATE(更新)由与三元组相关联的<AccessControlPolicy>指定的目标语义三元组的特权。也可能会验证<ontologyRef>并确定FilterCriteria是否有效。最后，在成功验证步骤221的UPDATE请求时，如果在步骤221的UPDATE请求中未提供，则创建语义三元组UPDATE操作命令。例如，在SPARQL Update语言中，“DELETE”和“INSERT”用于更新三元组。

继续参考图20，在步骤223，在语义图存储154中进行语义更新操作。例如，也可以通过SPARQL 1.1Update来提供可用于映射UPDATE操作的这些图管理操作：1)CREATE：在支持空图的存储器中创建新图形；2)COPY：修改图以包含另一个图的副本；3)MOVE：将所有数据从一个图移动到另一个图；4)ADD：将所有数据从一个图复制到另一个图；或5)DROP：删除图及其所有内容。在步骤224，用UPDATE操作结果编写响应。在步骤225，存在语义三元组UPDATE操作响应。该响应可以包括1)To：始发者ID(例如，AE ID或SE ID)和From：接收者ID(例如，SE ID)；2)参数：RequestStatus(成功)、RequestID；以及3)内容：SemanticTriples(如果ResponseType是NoACKsync)。

图21示出了用于DELETE语义三元组的示例性操作流程。在步骤231，发送语义三元组DELETE操作请求。步骤231的请求可以包括1)To：SemanticGraphStore和From：始发者ID(例如AE ID或SE ID)；2)操作：DELETE；3)参数：RequestID、SemanticTripleIDs、ContentFormat(例如，RDF XML)、FilterCriteria、ResultantContent；以及4)内容：SemanticTriples。

继续参考图21，在步骤232，例如在接收者152处发生语义三元组DELETE操作处理。在语义接收者152(例如，语义图存储154)中可以有对语义三元组DELETE操作的验证。验证可能包括以下内容。确定始发者151是否具有DELEET(删除)由与三元组相关联的<AccessControlPolicy>指定的目标语义三元组的特权。也可以确定FilterCriteria是否有效。最后，在成功验证步骤231的DELETE请求时，如果在步骤231的请求中未提供，则创建语义三元组DELETE操作命令。例如，在SPARQL更新语言中，“DELETE”和“CLEAR”以去除在特定的图中的所有三元组。

继续参考图21，在步骤233，在语义图存储154中进行语义DELETE操作。例如，通过SPARQL 1.1Update也可以提供可用于映射DELETE操作的这些图管理操作：1)MOVE：将所有数据从一个图移动到另一个图；或2)DROP：删除图及其所有内容。在步骤234，用DELETE操作结果编写响应。在步骤235，存在语义三元组DELETE操作响应。该响应可以包括1)To：始发者ID(例如，AE ID或SE ID)和From：接收者ID(例如，SE ID)；2)参数：RequestStatus(成功)、RequestID；以及3)内容：SemanticTriples(如果ResponseType是NoACKsync)。

如本文所讨论的，基于诸如具有图视图的访问控制或具有<AccessControlTriples>的访问控制之类的方法，由<AccessControlPolicyIDs>指定的<AccessControlPolicy>可用于语义图存储中的访问控制。参照具有图视图的访问控制，语义图存储的图视图(图49A中所示的示例)是在基础图存储上构建的子图，其可以通过提供对与应用相关的数据的专门配置的访问来增强数据的可用性，或通过根据授予的访问特权访问数据来实现对数据的访问控制。图视图方法可以包括如图49B所示的以下步骤。在步骤311，可以根据<AccessControlPolicy>指定的每个访问控制规则创建不同的图视图(例如，患者A的图视图304、患者B的图视图306或医生D的图视图308)。图视图304可以是具有患者A的可访问三元组的患者A的子图。图视图306可以是具有患者B的可访问三元组的患者B的子图。图视图308可以是患者不能访问的医生D的三元组。圆圈309可以是医生D的图视图(例如，具有医生D的可访问的三元组的医生D的子图，其为医生D的三元组、患者A的三元组和患者B的三元组的集合)。

继续参考步骤311，存在基于访问控制策略来创建图视图的多种方式。在第一种方式中，可以构建具有子本体论参考模型的图视图的子图。可以基于访问控制策略配置该子图，然后可以在该子图中进行语义查询。在第二种方式中，可以按照以下示例所示构建通过语义查询的图视图的子图。

图视图304(例如，患者A的图视图)：

继续参考图49B，在步骤312，针对AE或SE的每个语义三元组操作请求，可以基于由目标语义三元组的<AccessControlPolicy>定义的始发者的特权来选择该视图。在步骤313，在所选择的视图中进行语义三元组操作，该视图仅包含始发者已经允许用于所请求的语义三元组操作的、来自语义图存储的那些语义三元组。

图49C示出了用于基于具有<AccessControlTriples>的访问控制的、由用于语义图存储中的访问控制的<AccessControlPolicyIDs>指定的<AccessControlPolicy>的示例性方法的概要。在步骤316，可以构建由语义图存储中的<AccessControlPolicy>指定的访问控制规则。在步骤317，目标SemanticTriples可以使用相关访问控制规则与它们的<AccessControlPolicyID>或<AccessControlPolicy>相关联。在步骤318，可以利用与允许始发者操作的访问控制规则相关联的选定语义三元组来进行语义三元组操作。

图52图示与语义图存储相关联的示例性访问控制策略。图22示出了用于语义图存储(例如，在图52中)中的访问控制策略的示例的示例性调用流程(方法)。图22的方法图示了如何使用访问控制信息与目标三元组并将它们一起插入到语义图存储中的示例。在图22的步骤240处，可以预先配置eHealth本体论参考模型(如图23中所示)，并且可以预先配置访问控制本体论模型(如图24所示)。在步骤241，始发者162请求在SE 163处创建<AccessControlPolicy>资源，其承载访问控制策略。在步骤242，SE 163在资源树中创建<AccessControlPolicy>资源。在步骤243，SE 163以成功结果的指示来响应始发者162。在步骤244，SE 163请求SE 164将该<AccessControlPolicy>插入到语义图存储中。在步骤245，SE 164在语义图存储中创建<AccessControlPolicy>。这可以包括使用访问控制本体(在图24中示出)来创建<AccessControlTriples>以表示<AccessControlPolicy>下的访问控制规则。并且在语义图存储中插入<AccessControlTriples>。

继续参考图22，在步骤246，SE 164以成功结果的指示来响应SE163。在步骤247，始发者162请求在语义图存储中创建<SemanticTriples>。在步骤248，SE 163将步骤247的请求转发到承载语义图存储的SE 164。在步骤249，SE 164进行语义三元组CREATE操作。SE164可以通过使用始发者162的ID和相关的<AccessControlPolicy>验证语义图存储中的CREATE操作。如果它不存在，<AccessControlPolicy>可以被创建。SE 164可以将<AccessControlPolicy>与待在语义图存储中创建的三元组绑定，如图25中所示。SE 164可以将与<AccessControlTriples>相关联的三元组插入到语义图存储中。在步骤250，SE 164可以以成功结果向SE 163发送消息。在步骤251，SE 163可以以成功结果来响应于始发者162。

参考图22，在步骤252，始发者161请求语义三元组RETRIEVE操作。在步骤253，SE163将步骤252的请求发送给SE 164。在步骤254，SE 164进行语义三元组RETRIEVE操作。SE164可以通过使用始发者161的ID来验证检索操作，并用<AccessControlPolicy>编写语义查询命令，如图26所示。SE 164可以用<AccessControlPolicy>进行查询。在步骤255，SE164以成功结果向SE 163发送消息。在步骤256，SE1 163以成功结果向始发者161发送消息。

一般而言，如果应用对由始发者161提供的三元组启动语义查询，则SE 164中的查询引擎执行查询搜索，该查询搜索自动使用插入语义图存储中的AccessControlTriple。这可能是由于<AccessControlTriples>与由始发者161创建的三元组之间的绑定。注意，查询AE或SE仅需要提供其标识，例如AE ID或SE ID，以标识访问控制规则，如图26中所示。

在图23、图24、图25、图26和图53A至图53C中示出在语义图存储中的访问控制的示例文件。尽管这些机制是集中式语义图存储的例子，但一般过程可以适用于所有种类的语义图存储。

下面讨论经由语义查询的资源发现。图54示出了用于执行包括语义查询的资源发现的示例性方法。在步骤321，始发者161(例如，AE或SE)可以向SE 164发送语义查询，SE164托管语义图存储。响应于该请求，SE 164可以在语义图存储中进行语义查询。在步骤322，响应于在步骤321处的成功查询，始发者161可以从SE 164接收一个或多个三元组或一个或多个三元组节点。在步骤323(其可以在接收步骤322的三元组之后)，始发者161可以向SE 164发送对资源的RETRIEVE请求，该SE 164托管资源树。该资源可以位于SE 164的资源树中，并且由指定到或者关联到在步骤322中接收的三元组或三元组节点的URI或URL(统一资源定位符)寻址。SE 164在资源树中执行检索操作。在可以响应于步骤323的步骤324中，始发者161从成功的检索操作接收三元组或三元组节点。

图27示出分布在分级资源树中的语义描述符的示例性架构。这种分布式架构具有多个特征。用于语义查询的临时语义图存储(例如，临时语义图存储330或临时语义图存储338)可以本地驻留在诸如oneM2M中的CSE的服务实体(例如，SE 331或SE 332)上，并且包括从在分级资源树中分布的语义描述符(例如，语义描述符333或语义描述符334)提取的语义三元组。包含语义三元组的语义描述符可以位于多个服务实体上的不同分级资源树上。例如，语义描述符334可以位于SE 332上的资源树337中并且位于SE 331上的资源树339中。诸如oneM2M中的AE的应用实体(例如，AE 335)可以经由诸如oneM2M中的Mca接口的接口AS340与SE 332进行通信，用于对于在资源树中的语义描述符资源进行诸如CREATE、RETRIEVE、UPDATE、DELETE等RESTful操作。SE 332可以经由诸如Mcc或Mcc'oneM2M中的接口的接口SS 336与另一个SE 331进行通信，以对于资源树中的语义描述符资源进行RESTful操作，例如，CREATE、RETRIEVE、UPDATE、DELETE等。

在分级资源树中的语义描述符上的诸如CREATE、RETRIEVE、UPDATE和DELETE之类的RESTful操作类似于对资源树中的其他资源的操作。正如在背景技术中所提到的，语义查询不同于语义搜索，并且语义查询应该对于语义图存储中链接的所有语义三元组进行。因此，本文公开用于语义查询目的的本地临时语义图存储。

图28示出了具有资源树中的分布的语义描述符的示例性语义查询。在步骤351，包括语义三元组RETRIEVE操作的请求可以由接收者332(即，SE 332)接收。该请求可以包括以下内容：1)目标资源的地址或ID(例如，To地址)；2)始发者ID(例如，AE ID或SE ID)；3)操作(例如，RETRIEVE)；4)参数(例如，RequestID、ContentFormat(例如-SPARQL)、FilterCriteria(是语义的)、ResultContent)；或5)内容(例如，QuerySemanticTriples)。在步骤352处，基于步骤351的请求，接收者332可以执行与语义三元组RETRIEVE操作相关联的处理。接收者332可以在资源树之间进行语义描述符发现。接收者332可以验证在资源树中的语义三元组RETRIEVE操作。例如，确定始发者335具有根据由<AccessControlPolicy>为每个语义描述符指定的访问控制策略规则来RETRIEVE(检索)在资源树中的语义描述符的特权。接收者332可以确定FilterCriteria是否有效。基于对RETRIEVE请求的成功验证，接收者332可以RETRIEVE所发现的语义描述符。接收者332可以从检索到的语义描述符中提取语义三元组，并将它们存放到本地临时语义图存储中。SPARQL更新操作可用于加载临时语义图存储。如果请求中未提供(例如，以SPARQL查询语言)，则接收者332可以构造语义查询命令。接收者332可以使用目标查询语义三元组和在临时语义图存储中的FilterCriteria来进行语义查询。接收者332可以去除临时语义图存储中的语义三元组(例如，全部)。在步骤353，接收者332可以将具有语义查询结果的消息编写并发送到始发者335。

这里考虑的是，临时语义图存储可以用于链接从在资源树中发现的语义描述符提取的语义三元组，例如，以形成用于语义查询的关系图。这个临时的语义图存储可以在每个语义查询之后被清除，然后被加载从对于另一个语义查询发现的语义描述符提取的另一组语义三元组。因此，临时语义图存储在每次查询之后可以不保留语义三元组，以确保形成查询图的语义三元组是允许创始者在该临时语义图存储中进行操作的唯一三元组。

这里公开的是在语义图存储和分级资源树中都具有语义描述符的混合架构。图29示出了在语义图存储和分级资源树中的语义描述符的示例性架构。混合架构可以具有以下特征。可以存在用于语义查询的集中式语义图存储360，其可能驻留在SE 361(例如，oneM2M中的CSE)上。集中式语义图存储360可以包括来自分布在分级资源树(例如，资源树364、资源树365或资源树366)中的语义描述符的语义三元组。可以存在资源树364的语义描述符368、资源树365的语义描述符369或资源树366的语义描述符370。如所示，包含语义三元组的语义描述符可位于多个服务实体上的不同分级资源树处。

继续参考图29，下面是语义描述符的示例性选项。在第一选项中，在资源树中的语义描述符是包含语义三元组的真实资源。CREATE、RETRIVE、UPDATE或DELETE的操作可以对于在一个或多个资源树中的语义描述符进行，就像对资源树中任何其他类型资源的操作一样。但是，每当对在资源树中的语义描述符进行操作时，集中式语义图存储360中的语义图可以与那些语义描述符同步。集中式语义图存储360可以用于语义查询和其他语义分析操作。这第一选项可以更多地考虑为分布式方法。

继续参考图29，在第二选项中，资源树中的语义描述符可以是不包含语义三元组的虚拟资源。对一个或多个资源树中的虚拟资源语义描述符进行的CREATE、RETRIVE、UPDATE或DELETE的操作可触发集中式语义图存储360中的实际操作。集中式语义图存储360可不仅用于语义查询也用于存储语义三元组。该第二选项可能更多地被认为是一种集中的方法。

参考图29，应用实体(例如，AE 367)可以经由接口AS 371(例如，oneM2M中的Mca接口)与服务实体(例如，SE 362)通信，以用于对于在资源树(例如，365)中的语义描述符资源(例如，语义描述符369)的诸如CREATE、RETRIEVE、UPDATE、DELETE等的RESTful操作，以及对于集中式语义图存储360中的语义三元组的语义查询。在一个示例中，SE 362可以经由接口SS 372(例如，在oneM2M中的Mcc或Mcc’接口)与另一个SE 363进行通信，用于对于资源树(例如，资源树364)中的语义描述符资源的诸如CREATE、RETRIEVE、UPDATE、DELETE等的RESTful操作，以及对于集中式语义图存储中的语义三元组的语义查询。在第一选项中，对于分级资源树中的语义描述符的RESTful操作(例如，CREATE、RETRIEVE、UPDATE和DELETE)与对资源树中其他资源的操作类似。对于第二操作，对于集中式语义图存储360中的语义三元组的诸如CREATE、RETRIEVE、UPDATE和DELETE之类的操作类似于关于集中式方法所描述的操作，类似于对资源树中的其他资源的操作。

图30示出了用于在资源树中使用语义描述符进行语义查询的示例性方法。在步骤375，接收者361(例如，SE 361)可以接收对语义三元组RETRIEVE操作的请求。在步骤376，基于步骤375的请求，接收者361可以处理语义三元组RETRIEVE操作。接收者361可以进行语义描述符发现。接收者361可以验证资源树中的语义三元组RETRIEVE操作。这可以包括确定始发者373具有根据由<AccessControlPolicy>为每个语义描述符指定的访问控制策略规则来检索资源树中发现的语义描述符的特权。另外还可以确定FilterCriteria是否有效。在第一选项中，基于对RETRIEVE操作的成功验证，接收者361可以RETRIEVE(检索)在资源树中发现的语义描述符。在RETRIEVE操作成功验证之后，接收者361可以用语义三元组列表构建图视图。在第一选项中，接收者361可以从检索到的语义描述符中提取语义三元组并且将它们存储到构造有图视图的语义图存储360中。如果请求中未提供(例如，以SPARQL查询语言)，则接收者361可以构造语义查询命令。接收者361可以在语义图存储中构造的视图内使用目标查询语义三元组和FilterCriteria进行语义查询。

在步骤377，接收者361可以构建并向AE 373发送消息(例如，响应)。注意，在图3中和此处的其他地方作为示例示出“使用图视图的访问控制”方案，但“使用<AccessControlTriple>的访问控制”方案也可以适用于第一选项或第二选项。

这里公开了允许启用在分布式语义描述符之间的关系的替代方法。跨越分布式描述的过滤或查询提供了在此描述的关于oneM2M中的常规语义过滤提议的其他方法的替代方案。请注意，在此讨论的集中式方法中所做的一般假设适用，以便语义描述可以是RDF三元组格式或不是此格式。这里，重点放在由语义实例创建的整体图上，并且因此公开了三元组形式的语义实例的示例性使用。术语“语义描述符”或“语义三元组”(复数)可用于任何格式(例如，RDF)的语义描述。可以使用用于单个语句(例如，RDF三元组)的术语“语义实例”。例如，可以通过SPARQL对于RDF三元组例示查询。

在该方法中寻址的分布式架构可以具有以下特征。语义描述符可以跨越单个服务实体上的不同分级资源树上的资源而定位。对于在几个服务实体上的语义操作的请求可以被分解成路由到各个服务实体的请求，因此这里所述的语义操作以分布在所寻址的服务实体内的描述符为目标。应用实体(AE)(例如，oneM2M中的AE)可以通过接口AS(例如，oneM2M中的Mca接口)与SE进行通信，用于对于资源中的语义描述符资源进行诸如CREATE、RETRIEVE、UPDATE、DELETE等的RESTful操作。SE可以经由接口SS(例如，oneM2M中的Mcc或Mcc'接口)与另一SE进行通信，以用于对于资源树中的语义描述符资源的RESTful操作，诸如CREATE、RETRIEVE、UPDATE、DELETE等。用于语义查询的临时语义图存储可以驻留在服务实体(SE)(例如，oneM2M中的CSE)上，并且包含从分级资源树中分布的语义描述符提取的语义三元组。请注意，在此架构中，通过访问控制策略来解决安全性和隐私问题，如关于oneM2M中的常规访问控制策略所述。语义描述符具有资源级策略，它确定哪些实体可以为每个CRUD操作访问它们。

一个重要的问题可能在于查询服务实体中可用的可能大量资源的语义描述符。有几种选择，例如下面讨论的选择。第一选择可以包括处理在整个SE树上的每个查询(例如，处理每个查询，就好像它是针对资源树的基础(例如，oneM2M中的CSEBase)，并且好像SE中的所有语义描述符与每个查询相关)。这可能被认为是一种低效的搜索方法。第二选择可以包括考虑操作目标的语义描述符来处理每个查询。针对关于在oneM2M中常规语义过滤提议所描述的情况，这可能导致针对<device12>的查询根本不使用在<操作X>处可用的语义描述符信息。第三选择可以包括使用在此讨论的oneM2M中的常规语义过滤提议中描述的resourceDescriptionLink方法处理每个查询。在这种情况下，包含多个共同概念的两个(或更多)描述符可能导致在相同的两个描述符之间建立若干链接。基于过程描述，每次遇到新的链接时，处理查询操作的实体将获取相应的语义描述符(在这种情况下对于操作X)。这将导致相同描述符的多次检索。另外，可以基于对描述符内容的语义理解来处理检索。第四选择可以包括处理对于在含义上相关的一组描述符的每个查询。基于将针对准确性交换查询效率的策略，可以使得该组更宽或更小。下面介绍的方法属于这一类。它具有使用注解时可用的知识的优点，该知识即关于语义实例或子图与其他如何相关的知识，因为它知道放置该实例或描述的地点(在哪个资源树级)。

图31示出了与常规做法相同的描述符之间的多个resourceDescriptionLinks的问题。在本公开中，与如在“oneM2M中的语义过滤提议”部分中讨论的解决方案相反，可以向具有相关内容的语义描述符提供彼此的链接，其中，所提供的链接位于嵌入语义描述符的语义实例中的相关概念之间。具体而言，公开了新的属性(例如，relatedSemantics)以将其添加到语义描述符资源，以向相关语义描述符提供链接。

使用oneM2M上下文中的语义描述符资源的示例，将属性relatedSemantics添加到<semanticDescriptor>资源，如图32中所示，它说明了relatedSemantics属性。

如针对本文所讨论的链接列表和链接组所描述的那样，存在可以为relatedSemantics属性设想的多种实现。在第一实现中，relatedSemantics属性可以包括到相关语义描述符的单独链接的列表。在第二实现中，relatedSemantics属性指向组。然而，对于这个选项，此处公开了<semanticGroup>资源，然而，通用<group>资源也可以用于此目的。

注意，在此上下文中，“相关”语义描述符的概念可以具有以下含义：如果为了语义查询的目的将两个或更多个语义描述符一起使用以形成更大的图，则该两个或更多个语义描述符是“相关的”。在此，提供了以初始的基于主题的方案为基础的第一示例和使用基于任意图的方案的第二示例，基于任意图的方案提供用于生成相关语义描述符的方案，例如用于决定语义描述符相关并提供相应链接。应该注意，这里介绍的提供描述符间链接的方法可以被认为与特定系统如何选择以实现最终决定两个或更多个语义描述符相关的算法无关。

下面将使用oneM2M分布图(其类似地与本文讨论的oneM2M中的常规语义过滤提议相关联)的以下示例。在此示例中，存储在独立资源中的图形包含彼此相关的信息：在第二个描述符中进一步描述来自第一个图的OperationA，并且在两者中都包含关系exposeesCommand和object commandK。在这种情况下，进一步的图描述(例如，在第一个图中具有主题commandK并且与资源operationA描述符相关的附加潜在三元组)可能会在图形之间创建额外的依赖关系。

图33示出了分布在不同语义描述符上的示例性图形。在一个示例中，可能会出现以下过滤请求：“查找具有服务的所有设备，该服务具有其输出量化温度方面的操作，并对具有output＝OutputX和command＝commandK的设备进行过滤”

以下是请求的对应SPARQL表示：

目标是使得能够提交更大的结果图的创建以针对SPARQL查询进行评估，如图34中所示。。

在该实现中，relatedSemantics属性包含指向与其他资源相关联的描述符的链接列表，其应与给定的<semanticDescriptor>资源中的描述符一起使用以执行语义查询。

图35是具有链接列表的示例使用或relatedSemantics属性。当更有限数量的语义描述符相关时，在像所提出的那个的情况下使链接列表变短是有用的。为了进一步简化这个选项，可以设想标准化的规则可能会指定所有子资源的语义描述符默认被认为是相关的，这意味着，如果查询被定向到父级，则所有的子资源描述符(如果存在的话)应该被自动添加到父级。通过这种方式，父级的relatedSemantics属性不需要包含指向子级的所有描述符的链接。

在该实现中，relatedSemantics属性包含指向新公开的资源<semanticGroup>的链接，如图36中所示。semanticGroupLinks用于识别要在执行语义查询时一起使用的描述符。单个语义资源的relatedSemantics属性将直接指向<semanticGroup>资源、semanticGroupLinks属性，或者可以指示关联的semanticGroupID。在上面的示例中，当跨<Device12>和<operationA>资源分布复合图形时，可能会形成<semanticGroup>资源。对于这个资源，可以分配semanticGroupID，例如56，并且semanticGroupLinks属性可以包括到相关语义描述的链接的列表，例如，指向<Device12>和<OperationA>的链接。在其他实现中，链接可以相反指向各个<semanticDescriptor>资源的每个描述符属性或者指向子<semanticDescriptor>资源本身。图37是具有<semanticGroup>的示例使用或relatedSemantics属性。

生成和维护分布式语义描述符之间的关系链接。分布式语义描述符架构可能依赖于利用语义技术的平台功能的可用性。这意味着存在语义启用的平台功能，其使用CRUD操作提供语义描述符。同样，可以使用CRUD操作来管理这些描述符，包括执行语义实例的更新。这些注释功能的总和被认为是语义注释功能。

这里讨论的是函数生成资源，其中，注释功能可以具有关于应该在何处存储生成的资源、应该如何设置访问控制属性等的规则和策略。

下面是可以在注释生成过程中使用的关系维持方案的示例，以便举例说明如何可以使用所提议的语义描述符链接的方法。

在前面部分中的示例依赖于已经使用图34中的较大图的语义注释功能，以如图33所示注释资源<Device12>和<operation A>。这是图的处理的逻辑表示。在具体实现中，该图的处理可以使用本地临时或永久三元组存储。这可能与本文讨论的混合方法不同，因为三元组存储是本地的并且不需要在服务实体之间共享。

然而，可以使用语义注释功能来生成在所创建的各种语义描述符之间的链接，并且在其生成子图和注释的同时填充relatedSemantics属性。

以下描述使用oneM2M Base Ontology(图8)作为示例。语义注释引擎使用这种本体来创建图34中的图，其用RDF表示。请注意，显示的文本没有进行格式化以有在描述符中的精确的RDF语法，而是它是整个图的概念表示。

下面提供以初始的基于主题的方案为基础的示例。在这种方案中，每个rdf：Description都存储在相应资源的语义描述符中，因此被命名为“基于主题的方案”。通过这种方法，当形成或更新其对象是另一资源的三元组时，注释引擎也会创建向在相同的<semanticDescriptor>资源中relatedSemantics属性内的输入。

使用图37的示例图，与资源<Device12>相关联的<semanticDescriptor>子资源的描述符和relatedSemantics属性将如图39中所示。请注意，在这种情况下，图分布在<Device12>、<OperationA>资源以及<Service23>和<OperationX>上。通过隔离相应的描述，最后三个资源的相应RDF可以很容易地从图38中提取出来。

如果使用用于填充<Device12>的<semanticDescriptor>资源中的relatedSemantics属性的链接列表方法，则会生成如图40所示的下面的列表。图40是使用链接列表方法时relatedSemantics属性的一个例子。

如果采用链接组方法，<Device12>的semanticDescriptor资源中的relatedSemantics属性可指向相应的<semanticGroup>资源。实际上，在<Service23>、<OperationA>和<output>的semanticDescriptor资源中的relatedSemantics属性指向相同的相应<semanticGroup>资源。在<semanticGroup>资源内，semanticGroupLinks属性可以包括如图41中所示的链接列表。图41是使用链接组方法时的semanticGroupLinks属性的示例。

使用基于任意图的方案的示例。使用基于任意图的方案允许任意图被存储在资源的语义描述符中，并且这是oneM2M规范中的当前假设。关于确定应该在何处存储整个图的各个部分，这种方法允许在注释引擎的实现时使用任何逻辑。

这和与用于启用分布式语义描述符之间的关系的讨论相关联的示例松散地关联，其中，存储在每个<Device12>和<operationA>中的图形包含具有与所述两个资源不同的主题的三元组。然而，我们应该注意到，在这个例子中，每个资源可以在其自身描述中包括与其本身相关的三元组，因此图的选择并不完全是任意的。

对于该示例，图38中的RDF中描述的复合图可以使用颜色、数字或某些其他机制来分别表示决定存储在<Device12>和<OperationA>的描述符中的信息。括号101处的线表示存储在两个位置的三元组。请注意，所示的文本没有被格式化以用于在描述符中的准确的RDF语法，而是它是整个图的概念表示，以及每个描述符内捕获的三元组的概念表示。

在该示例中，与资源<Device12>和<OperationA>相关联的语义描述符将如图42和图43中所示。图42是在基于任意图的方案中的用于<Device12>的示例语义注释。图43是在基于任意图的方案中的<OperationA>注释的示例。

如果在这种情况下采用链接列表方法，则<Device12>和<OperationA>的relatedSemantics属性将指向彼此。这将表明，当跨越描述符之一完成语义查询时，另一个也应该被检索以完成该图以用于查询目的。

如果采用链接组方法，则<Device12>和<OperationA>两个的relatedSemantics属性将指向同一<semanticGroup>资源，其中，所述semanticGroupLinks属性将包含在图44中所示的链接列表中。图44是使用链接组方法时的semanticGroupLinks属性的示例。

语义描述符之间的关系的维护也由生成这些方案的注释引擎完成，并且其同样与描述符之间的“相关”关系已经建立的方式无关。这里，存在诸如“基于主题的方案”和“基于任意图的方案”的示例性方案。对于基于主题的方案，同一描述符中的三元组具有相同的主题，并且主题是父资源。在所述任意方案中，三元组可以任意存储，而不是按主题存储。

维护方法对于组方法更简单，因为当描述符被创建、更新或删除以使得关系改变时，更新主要发生在<semanticGroup>资源中，尤其是对于较大的相关描述符组。相比之下，只有少数描述符是相关的时，维护链接列表实现中的关系才是最优的。

为了使得能够在使用或不使用<semanticGroup>资源的情况下对跨由relatedSemantics属性连接的多个资源上存储的语义描述进行语义过滤，语义查询引擎可以使用图45的步骤。图45示出了使用relatedSemantics方法进行语义查询的示例性方法。在步骤381，接收者152通过验证请求参数来处理接收到的RETRIEVE请求(步骤380)。尽管在这里讨论了在这种情况下从步骤380开始的RETRIEVE请求，但是其他语义资源发现通常是可应用的。在步骤382，接收者152在相应的字段中发现与所寻址的资源相关联的语义描述符。semanticDescriptor本身可能有一个叫做relatedSemantics的属性，它标识要获取的其他描述符。在步骤383，接收者152验证始发者151对消息目标(例如，语义描述符)具有RETRIEVE特权，然后提取描述符和relatedSemantics属性。如果没有对于消息目标的特权，则生成相应的返回码。语义描述符的内容可以在本地保存，其可以作为文档或在本地或临时图形存储中保存。文档是语义描述符的表示，如图42中那样。图存储如图25那样。相关语义可以用于生成要检索的其他语义描述符的列表(即，集合)。该列表可以直接被提供，或通过访问relatedSemantics属性指向的<semanticGroup>资源来提供。如果始发者151在<semanticGroup>处没有RETRIEVE特权，则不会收集其他描述符。

继续参考图45，在步骤384，接收者152可以使用在先前步骤中生成的相关描述符的列表。接收者152根据访问控制规则检索各个描述符属性中的每一个的内容。如果允许访问，则将链接的<semanticDescriptor>资源的每个描述符属性的内容添加到正在执行SPARQL请求的内容。受SPARQL请求限制的完整或放大内容被提供给SPARQL引擎进行处理。在步骤385，接收者152执行在结果图上提供的语义查询命令(或其他语义资源发现)。在步骤386，接收者152编写对语义查询的响应。在步骤387，如果本地图存储已被使用，则接收者可以基于本地规则和策略来维护或删除所生成的图。

所公开的用于语义过滤或发现的方法的技术效果可以包括以下：1)可以找到所需的语义信息；2)基于资源的访问控制可能在一些情况下更容易实施，因为在操作的执行时间在访问信息并且可以应用请求者的访问特权；3)在处理之前收集要由SPARQL引擎处理的内容，这可以允许使用外部的、非oneM2M特定的语义查询引擎；或4)包含多个通用概念的描述符仅通过一个链接进行链接，这可以允许更容易地避免重复内容被考虑用于请求处理。

使用与“启用分布式语义描述符之间的关系”相关联的示例，使用上述步骤(例如，图45)构建复合图(图34)并将其提供给SPARQL引擎以进行处理。SPARQL引擎可以使用本地三元组存储以便临时存储图，在这种情况下，这可能会导致HYBRID(混合)方法。

以下讨论的是基于<semanticGroup>的示例。在给定分布式语义描述符的实现的情况下，下面介绍的增强型<semanticGroup>资源不仅可以提供用于维护描述符之间的关系，而且可以提供用于使得语义过滤操作更高效。

图46图示了增强的<semanticGroup>资源的示例。增强包括引入资源<semanticFanOutPoint>，它可以是虚拟资源，并允许<semanticGroup>资源成为语义查询的目标而不是单个资源。当查询始发者(例如，始发者151)基于先前的发现具有对资源树的理解时，这可以添加一层有用性。通过解决针对<semanticGroup>资源的<semanticFanOutPoint>的查询，技术效果可能是在接收者152处的语义引擎可以更容易地维护和搜索与整个组相关联的合成图。本地三元组存储贮存器、缓存等可以进一步使得在接收者处的语义引擎中的查询的处理更加高效，以获得更快的结果。另外，<semanticGroup>资源可用于将查询定位到属于不同SE的资源。如果驻留在第一SE上的<semanticGroup>资源分别包括第二SE和第三SE上的成员资源，则可以将检索操作扇出到第二SE和第三SE上的相应资源。然后可以如上所述在各个SE内处理查询。

当使用<semanticGroup>资源时的另一增强可以通过提供用于使用包含在语义描述符中的每个图的图名称的指令来进行，例如，可以命名创建的每个语义描述符并且应该将唯一名称分配给它。另外可以使得图名称与描述符的位置相关联。命名可能是分级的，使得组中的所有图都可以一起被寻址，或者分配的名称可以彼此独立。无论哪种情况，都可以使用新的属性groupGraphNames通过列表或根名称为组中的图提供名称。

该方法的技术效果可以是通过使语义操作的始发者尽可能具体或尽可能宽来向他们提供更大的粒度。在接收者端，语义引擎可能更有效率，这样当接收到寻址到<semanticFanOutPoint>但其中SPARQL有效载荷指示特定图的查询请求时，引擎使用图名称和semanticGroupLinks中提供的链接之间的关系来仅处理与给定图形关联的描述符。

考虑图4中所示的oneM2M架构，语义图存储和语义存储管理器可以驻留在CSF语义中，并且资源树和数据存储管理器可以驻留在CSF数据管理和存储库中。图47示出考虑oneM2M的具有语义图存储的示例性架构。图48示出了使用oneM2M公开的方法的示例性资源树。如图48所示，在<CSEbase>下添加新的资源<SemanticGraphStore>。在一个示例中，不同semanticDescriptor资源的relatedSemantics属性可以指向<semanticGroup>来指示相关的描述符。一旦完成，组的semanticFanOutPoint可用于发送涉及所有相关描述符的语义操作。

图50示出了可以基于这里讨论的方法和系统生成的示例性显示(例如，图形用户界面)。显示界面901(例如，触摸屏显示)可以在框902中提供与用于语义物联网的RESTful操作相关联的文本，诸如具有访问控制的eHealth语义查询，如本文所讨论的。在另一个示例中，本文讨论的任何步骤的进展(例如，发送的消息或步骤的成功)可以被显示在框902中。另外，图输出903可以被显示在显示界面901上。图输出903可以是语义图存储的拓扑或本文讨论的任何方法或系统(例如，图18至图21等)的进展的图输出等。图53A至53C图示了可以在显示界面901上的输出。可能存在具有选择下载格式的选项的查询结果。如所示出的，可以存在如在图53A至53C中的示例以及相应结果中提供的所示的Svalue、Dvalue、语义描述符和样本。

图51A是其中可以实现与用于语义物联网的RESTful操作相关联的一个或多个公开的概念的示例机器对机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图(例如，图16-图49C和图54)。通常，M2M技术为IoT/WoT提供构建块，任何M2M设备、M2M网关或M2M服务平台都可能是IoT/WoT的组件以及IoT/WoT服务层等。

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

如图51A所示，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、蓝牙)、直接无线电链路和有线的各种网络进行通信。

参考图51B，所示的场域中的M2M服务层22为M2M应用20(例如eHealthcare App)、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'可以由一个或多个服务器、计算机或虚拟机(例如，云/计算/存储集群等)等来实现。

还参考图51B，M2M服务层22和22'提供了各种应用和垂直行业可以利用的一组核心的服务交付能力。这些服务能力使得M2M应用20和20'能够与设备进行交互，并执行诸如数据收集、数据分析、设备管理、安全、计费、服务/设备发现等的功能。这些服务能力使应用免于实现这些功能的负担，从而简化了应用开发并降低了上市的成本和时间。服务层22和22'还使得M2M应用20和20'能够通过各种网络12和12'与服务层22和22'提供的服务相结合进行通信。

在一些示例中，如本文所讨论的，M2M应用20和20'可以包括使用用于语义物联网的RESTful操作进行通信的期望的应用。M2M应用20和20'可以包括各种行业中的应用，例如但不限于交通、健康和保健、连接的家庭、能源管理、资产跟踪以及安全和监视。如上所述，跨系统的设备、网关和其他服务器运行的M2M服务层支持诸如数据收集、设备管理、安全、计费、位置跟踪/地理围栏、设备/服务发现和传统系统集成，并且将这些功能作为服务提供给M2M应用20和20'。

本申请的用于语义物联网的RESTful操作可以被实现为服务层的一部分。服务层是一个软件中间件层，其通过一组应用编程接口(API)和底层网络接口支持增值服务能力。M2M实体(例如，可以通过硬件和软件的组合来实现的M2M功能实体，诸如设备、网关或服务/平台)可以提供应用或服务。ETSI M2M和oneM2M都使用可能包含本申请的用于语义物联网的RESTful操作的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在M2M设备(在此，其被称为设备SCL(DSCL))、网关(在此，其被称为网关SCL(GSCL))或网络节点(在此，其被称为设备SCL作为网络SCL(NSCL))。oneM2M服务层支持一组通用服务功能(CSF)(例如，服务能力)。一组一个或多个特定类型的CSF的实例被称为公共服务实体(CSE)，其可以驻留在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。此外，本申请的用于语义物联网的RESTful操作可以被实现为使用面向服务的架构(SOA)或面向资源的架构(ROA)来访问诸如本申请的用于语义物联网的RESTful操作的服务的M2M网络的一部分。

如本文所讨论的，服务层可以是网络服务架构内的功能层。服务层通常位于诸如HTTP、CoAP或MQTT的应用协议层之上，并为客户端应用提供增值服务。服务层还提供到在较低资源层(例如控制层和传输/访问层)处的核心网络的接口。服务层支持多种类型的(服务)能力或功能，包括服务定义、服务运行时使能、策略管理、访问控制和服务群集。最近，一些行业标准组织(例如，oneM2M)一直在开发M2M服务层以解决与将M2M类型的设备和应用集成到诸如因特网/网络、蜂窝、企业和家庭网络等的部署中相关的挑战。M2M服务层可以向各种设备的应用提供对由服务层支持的上述能力或功能的集合或组的访问，所述集合或组可以被称为CSE或SCL。一些示例包括但不限于通常可以由各种应用使用的安全、计费、数据管理、设备管理、发现、配置和连接管理。这些能力或功能通过利用由M2M服务层定义的消息格式、资源结构和资源表示的API来提供给这样的各种应用。CSE或SCL是一个功能实体，其可以通过硬件或软件实现，并提供对各种应用或设备开放的(服务)能力或功能(即这些功能实体之间的功能接口)，以便它们使用这些能力或功能。

图51C是诸如M2M终端装置18(例如，AE367、AE335或始发者151)或M2M网关装置14(例如，SE361或接收者152)的示例M2M装置30的系统图。如图51C所示，M2M设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、键区40、显示器/触摸板42、不可移除存储器44、可移除存储器46、电源48、全球定位系统(GPS)芯片组50和其他外围设备52。应当理解，在保持与所公开的主题相一致的同时，M2M设备30可以包括前述元件的任何子组合。M2M设备30(例如，服务实体163、图22的接收者和图22的始发者161、图47的MN-CSE、图29的应用实体373以及图47的IN-CSE等)可以是执行所公开的用于语义物联网的RESTful操作的系统和方法的示例性实现。

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

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

另外，尽管在图51C中将发送/接收元件36描绘为单个元件，M2M设备30可以包括任何数量的发送/接收元件36。更具体地，M2M设备30可以采用MIMO技术。因此，在一个示例中，M2M设备30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

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

处理器32可以从诸如不可移除存储器44或可移除存储器46之类的任何类型的合适存储器中访问信息并将数据存储在其中。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒和安全数字(SD)存储卡等。在其他示例中，处理器32可以从物理上不位于M2M设备30(例如，服务器或家庭计算机)上的存储器访问信息并将数据存储在该存储器中。处理器32可以被配置为响应于这里描述的一些示例中的步骤是成功还是不成功(例如，语义三元组CREATE操作请求或语义三元组RETRIEVE操作请求等)来控制显示器或指示器42上的照明图案、图像或颜色，或者以其他方式指示如本文所讨论的用于语义物联网的RESTful操作的状态以及相关联的组件。显示器或指示器42上的控制照明图案、图像或颜色可以反映本文中图示或讨论的图中的任何方法流程或组件的状态(例如，在此的图16-图49C和图52-图54等)。这里公开了用于语义物联网的RESTful操作的消息和过程。消息和过程可以被扩展以提供可以在显示器42上显示的界面/API，以供用户经由输入源(例如，扬声器/麦克风38、键区40或显示器/触摸板42)请求资源相关资源，并请求、配置或查询用于语义物联网的RESTful操作等等。

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

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

处理器32还可以耦合到其他外围设备52，其可以包括提供附加特征、功能或有线或无线连接的一个或多个软件或硬件模块。例如，外围设备52可以包括各种传感器，例如，加速计、生物识别(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其他互连接口、振动设备、电视收发器、免提耳机、蓝牙模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块和互联网浏览器等。

发送/接收元件36可以包含在其他设备或装置中，诸如传感器、消费电子产品、诸如智能手表或智能衣服的可穿戴设备、医疗或eHealth设备、机器人、工业设备、无人驾驶飞机、诸如汽车、卡车、火车或飞机的车辆。发送/接收元件36可以经由一个或多个互连接口(例如，可以包括外围设备52中的一个的互连接口)连接到此类设备或装置的其他组件、模块或系统。

图51D是其上例如可以实现图51A和图51B的M2M服务平台22的示例性计算系统90的框图。计算系统90(例如，M2M终端设备18或M2M网关设备14)可以包括计算机或服务器，并且可以主要由计算机可读指令来控制，计算机可读指令可以是软件的形式，无论何地或通过任何手段这样的软件被存储或访问。这样的计算机可读指令可以在中央处理单元(CPU)91内执行以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单片CPU实现。在其他机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的处理器，其执行附加功能或辅助CPU 91。CPU 91或协处理器81可以接收、生成和处理与所公开的用于语义物联网的RESTful操作的系统和方法有关的数据，诸如如图18的步骤202中那样处理对CREATE的请求。

在操作中，CPU 91获取、解码并执行指令，并且通过计算机的主数据传输路径(即，系统总线80)将信息传递到其他资源和从其他资源传递信息。这种系统总线连接计算系统90中的组件并定义用于数据交换的媒介。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的例子是PCI(外围组件互连)总线。

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

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

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

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

应该理解的是，可以以存储在计算机可读存储介质上的计算机可执行指令(例如，程序代码)的形式来体现本文描述的任何或全部系统、方法和过程，所述指令在被机器(诸如计算机、服务器、M2M终端设备或M2M网关设备等)执行时执行或实现在此描述的系统、方法和过程。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式来实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。从这里的描述可以明显看出，存储介质应该被解释为美国法典第35篇第101节(35U.S.C§101)下的法定主题。计算机可读存储介质包括RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备、或任何其他可用于存储所需信息并可由计算机访问的物理介质。

在描述本公开的主题——用于语义物联网的RESTful操作——的优选方法、系统或装置时，如附图所示，为了清楚起见采用了特定术语。然而，所要求保护的主题不旨在局限于如此选择的特定术语，并且应该理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等同物。

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

本书面描述使用示例来公开本发明，包括最佳模式，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员可以想到的其他示例(例如，本文公开的示例性方法之间跳过步骤、组合步骤或者添加步骤)。如果其他示例具有不与权利要求的字面语言不同的结构元件，或者如果它们包括与权利要求的字面语言无实质区别的等同结构元件，则这些其他示例意图处于权利要求的范围内。

Claims (20)

1.一种用于语义资源发现的装置，所述装置包括：

处理器；以及

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

接收包括语义资源发现的消息；

确定要检索的一组语义描述符，其中所述一组语义描述符与所述消息的目标相关；以及

基于所述一组语义描述符，检索所述语义描述符的列表的各个描述符属性的内容。

2.根据前述权利要求中任一项所述的装置，所述操作还包括：

基于所述各个描述符属性的内容来生成语义图；以及

提供用于在所述语义图上进行语义资源发现的指令。

3.根据前述权利要求中任一项所述的装置，其中，所述各个描述符属性中的至少一个被存储在不同的装置上。

4.根据前述权利要求中任一项所述的装置，其中，经由组资源来提供所述一组语义描述符。

5.根据前述权利要求中任一项所述的装置，其中，要检索的所述一组语义描述符包括对于所述语义描述符的统一资源标识符的列表。

6.根据前述权利要求中任一项所述的装置，其中，所述语义描述符是资源。

7.根据前述权利要求中任一项所述的装置，所述操作还包括验证始发者装置具有针对所述消息的目标的访问权，其中所述消息的目标是第一语义描述符。

8.根据前述权利要求中任一项所述的装置，所述操作还包括验证始发者装置具有针对所述一组语义描述符中的每个语义描述符的访问权。

9.根据前述权利要求中任一项所述的装置，所述操作还包括将所述消息的目标的属性的内容保存为文档，其中所述消息的目标是第一语义描述符。

10.根据前述权利要求中任一项所述的装置，所述操作还包括将所述生成的语义图保存在临时图存储中。

11.根据前述权利要求中任一项所述的装置，所述操作还包括：生成与在所述消息中接收到的语义三元组和资源访问控制信息相关联的访问控制三元组，其中所述访问控制三元组随后被存储在所述语义图中。

12.一种用于语义资源发现的方法，所述方法包括：

接收包括语义资源发现的消息；

确定要检索的一组语义描述符，其中所述一组语义描述符与所述消息的目标相关；以及

基于所述一组语义描述符，检索语义描述符列表的各个描述符属性的内容。

13.根据权利要求12所述的方法，所述操作还包括：

基于所述各个描述符属性的内容来生成语义图；以及

提供用于在所述语义图上进行语义资源发现的指令。

14.根据权利要求12至13中任一项所述的方法，其中，经由组资源来提供所述一组语义描述符。

15.根据权利要求12至14中任一项所述的方法，其中，要检索的所述一组语义描述符包括对于所述语义描述符的统一资源标识符的列表。

16.根据权利要求12至15中任一项所述的方法，其中，所述语义描述符是资源。

17.根据权利要求12至16中任一项所述的方法，还包括验证始发者装置具有针对所述消息的目标的访问权，其中所述消息的目标是第一语义描述符。

18.根据权利要求12至17中任一项所述的方法，还包括将所述生成的语义图保存在临时图存储中。

19.根据权利要求12至18中任一项所述的方法，还包括生成与在所述消息中接收到的所述语义三元组和所述资源访问控制信息相关联的访问控制三元组，其中所述访问控制三元组随后被存储在所述语义图中。

20.一种包括计算机可读介质的计算机程序产品，所述计算机可读介质上具有包括程序指令的计算机程序，所述计算机程序可加载到数据处理单元中并且被适配成当所述计算机程序由所述数据处理单元运行时使所述数据处理单元执行根据权利要求12至19中任一项所述的方法步骤。