CN109845221A

CN109845221A - 用于服务层的访问控制策略同步

Info

Publication number: CN109845221A
Application number: CN201780060536.4A
Authority: CN
Inventors: 王重钢; 李鸿堃; 李旭; D·N·希德; 李庆光; C·M·米拉迪恩
Original assignee: Convida Wireless LLC
Current assignee: Convida Wireless LLC
Priority date: 2016-09-29
Filing date: 2017-09-29
Publication date: 2019-06-04
Anticipated expiration: 2037-09-29
Also published as: KR20190067193A; JP7037555B2; US11005888B2; WO2018064455A1; EP3520360A1; US20180288098A1; KR102219730B1; JP2019537100A; CN109845221B

Abstract

在创建、更新或删除访问控制策略(ACP)资源的任何时候，服务层环境中的方法、系统和装置都可以创建、更新或删除访问控制策略三元组。此外，方法解决潜在的频繁和不必要的ACP三元组管理。

Description

用于服务层的访问控制策略同步

相关申请的交叉引用

本申请要求于2016年9月29日提交的标题为“Access Control PolicySynchronization for Service Layer”的美国临时专利申请No.62/401,623的权益，其内容通过引用结合于此。

背景技术

语义Web

语义Web是万维网联盟(W3C)通过标准对Web的扩展。这些标准促进Web上的公共数据格式和交换协议，最基本的是资源描述框架(RDF)。

语义Web涉及以专门为数据设计的语言发布：资源描述框架(RDF)、Web本体语言(OWL)以及可扩展标记语言(XML)。这些技术组合，以提供经由链接数据的网来补充或替换Web文档内容的描述。因此，内容可以表现为存储在Web可访问数据库中的描述性数据，或者作为文档中的标记，特别是散布在XML中的可扩展HTML(XHTML)，或者更常见的是纯粹用XML，其中布局或渲染提示分开存储。

语义Web堆栈

语义Web堆栈说明由W3C指定的语义Web的体系架构，如图1中所示。下面讨论如图1中所示的部件的功能和关系。XML为文档内的内容结构提供元素语法，但没有将语义与其中包含的内容的含义相关联。在大多数情况下，XML目前不是语义Web技术的必要部件，因为存在替代语法，诸如Turtle。Turtle是事实上的标准，但尚未通过正式的标准化过程。XMLSchema是一种用于提供和限制XML文档内包含的元素的结构和内容的语言。RDF是用于表达数据模型的简单语言，其引用对象(“web资源”)及其主语-谓词-宾语形式的关系，例如，S-P-O三元组或RDF三元组。基于RDF的模型可以用各种语法表示，例如RDF/XML、N3、Turtle和RDFa。RDF是语义Web的基本标准。

RDF图是有向图，其中边表示RDF三元组的“谓词”，而图节点表示RDF三元组的“主语”和/或“宾语”。换句话说，如RDF三元组中描述的链接结构形成有向RDF图。RDF Schema(例如，RDF Schema 1.1.)扩展了RDF，并且是用于描述基于RDF的资源的特性和类的词汇表，具有这些特性和类的通用层次结构的语义。OWL为描述特性和类而添加了更多词汇：其中包括类之间的关系(例如，不相交)、基数(例如“确切地一个”)、相等性、更丰富的特性类型、特性的特征(例如，对称性)和枚举类。

SPARQL(例如，SPARQL 1.1)是用于语义web数据源的协议和查询语言，以在Web或RDF存储装置(例如，语义图存储装置)中查询和操纵RDF图内容(例如，RDF三元组)。SPARQL1.1 Query(用于RDF图的查询语言)可以用于表达跨不同数据源的查询，无论数据是本机存储为RDF还是经由中间件被视为RDF。SPARQL包含查询必需和可选图模式及其接合和分离的功能。SPARQL还支持聚合、子查询、否定、通过表达式创建值、可扩展值测试以及通过源RDF图约束查询。SPARQL查询的结果可以是结果集或RDF图。SPARQL 1.1 Update是用于RDF图的更新语言。它使用从用于RDF的SPARQL查询语言导出的语法。对语义图存储装置中的图的集合执行更新操作。提供操作以在语义图存储装置中更新、创建和移除RDF图。RIF是W3C规则交换格式。它是用于表达计算机可以执行的Web规则的XML语言。RIF提供多个版本，称为方言。它包括RIF基本逻辑方言(RIF-BLD)和RIF制作规则方言(RIF PRD)。

语义搜索和语义查询

关系数据库以隐式方式包含数据之间的关系。例如，客户和产品之间的关系(存储在两个内容表中并利用附加的链接表连接)仅在开发人员编写的查询语句(例如，在关系数据库的情况下使用SQL)中存在。编写查询需要确切了解数据库模式。许多关系数据库被建模为在分层数据库中，其中数据被组织成树状结构。数据被存储为通过链接彼此连接的记录。分层数据库模型中的记录与关系数据库模型中的行(或元组)对应，并且实体类型与表(或关系-父和子)对应。可以由SQL或非SQL搜索引擎进行记录的搜索或查询。

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

链接的数据(Linked-Data)以显式方式包含数据之间的所有关系。在为关系数据库描述的上面提到的示例中，不需要编写查询代码。可以为每个客户自动获取正确的产品。虽然这个简单的示例是微不足道的，但是当创建信息的网络时，链接的数据的真正力量发挥作用(具有如城市、州和国家等地理空间信息的客户；具有在子类别和超类别内的类别的产品)。现在，系统可以自动回答更复杂的查询和分析，以查找特定位置与产品类别的连接。省略了针对这种查询的开发工作。通过遍历信息网络并找出匹配(也称为数据图遍历)来进行语义查询。

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

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

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

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

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

oneM2M功能体系架构

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

CSE包含称为公共服务功能(CSF)的多个逻辑功能，诸如“发现”和“数据管理和存储库”。图4图示了由oneM2M定义的其中一些CSF。

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

oneM2M中的访问控制策略

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

<accessControlPolicy>资源包含表1中指定的属性。privileges和selfPrivileges属性中表示的访问控制规则集由以下更详细描述的3元组组成：accessControlOriginators、accessControlContexts和accessControlOperations。

表1：<accessControlPolicy>资源的属性

accessControlOriginators是访问-控制-规则元组中的强制参数。它表示将被允许使用这个访问控制规则的Originators集。Originators集被描述为参数的列表，其中参数的类型可以在列表内变化。表2描述了accessControlOriginators中所支持的参数类型。

表2.accessControlOriginators中的参数类型

当originatorID是包含<AE>或<remoteCSE>作为成员的<group>资源的资源ID时，资源的托管CSE应检查请求的始发者是否与<group>资源的memberlDs属性中的成员之一匹配(例如，通过检索<group>资源)。如果无法检索<group>资源或不存在该资源，那么应拒绝该请求。

accessControlContexts是包含列表的访问-控制-规则元组中的可选参数，其中列表的每个元素(当存在时)表示被允许使用这个访问控制规则的上下文。每个请求上下文由参数集描述，其中参数的类型可以在集合内变化。表3描述了accessControlContexts中支持的参数的类型。

对于由CSE进行的访问控制策略检查，应考虑以下OriginatoraccessControlContexts。

表3.accessControlContexts中的参数类型

accessControlOperations是访问-控制-规则元组中的强制参数，其表示使用这个访问控制规则授权的操作集。表4描述了由accessControlOperations授权的受支持操作集。

对于由CSE进行的访问控制策略检查，应考虑以下accessControlOperations。

表4.accessControlOperations中的参数类型

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

accessControlPolicylDs是在oneM2M-TS-0001 oneM2M FunctionalArchitecture-V2.9.0中定义的许多oneM2M资源的公共属性。这个属性包含<accessControlPolicy>资源的标识符列表。在被引用的<accessControlPolicy>资源中定义的privileges属性确定允许谁为具体目的(例如，检索、更新、删除等)访问包含这个属性的资源。

如果资源类型没有accessControlPolicylDs属性定义，那么用于那个资源的accessControlPolicylDs以不同的方式被管理，例如，与父资源相关联的accessControlPolicylDs可以应用于不具有accessControlPolicylDs属性定义的子资源，或用于访问的特权由系统修复。请参阅对应的资源类型定义和过程，以了解在这种情况下如何处理访问控制。

如果资源类型确实具有accessControlPolicylDs属性定义，但未设置(可选的)accessControlPolicylDs属性，或者将其设置为与有效的现有<accessControlPolicy>资源不对应的值，或者它引用无法到达的<accessControlPolicy>资源(例如，因为它位于脱机或无法到达的远程CSE上)，那么系统默认访问特权应适用。

所有资源当且仅当特权(即，存储为<accessControlPolicy>资源的privileges或selfPrivileges属性)允许它时才是可访问的，因此所有资源都应具有相关联的AccessControlPolicylDs属性，或者显式地(在资源本身中设置属性)或者隐式地(或者通过使用父特权或者系统默认策略)。这意味着，如果Originator在创建资源期间未提供具体的accessControlPolicylDs，那么系统应提供默认访问权限。

oneM2M中的语义启用

如图6中所示的<semanticDescriptor>资源被用于存储与资源和潜在子资源有关的语义描述。可以根据本体提供这样的描述。语义信息被oneM2M系统的语义功能使用，并且也可供应用或CSE使用。<semanticDescriptor>资源应包含表5中指定的属性。

表5：<semanticDescriptor>资源的属性

oneM2M中的语义过滤建议-通过在请求操作中指定过滤标准来支持通用过滤(oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0第8.1.2节)。为了提供语义过滤，在oneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0第8.5.4节中提出了请求操作过滤条件的附加值，其定义如下表所示。可以使用根据用于评估过滤标准的一般规则的多个实例，意味着应用“OR”语义，例如，如果语义过滤器中的一个或多个与语义描述匹配，那么语义过滤条件的总结果为真。要注意的是，下表中的语义在neM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0中定义，并且它与oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0中的请求参数semanticFilter对应。当semanticFilter参数中包含的SPAQRL查询与父资源的子资源<semanticDescriptor>之一中的语义三元组匹配时，意味着这个语义过滤成功并且将返回对应的父资源。

表6.semantic过滤标准

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

以下是在oneM2M TR-0007中给出的语义过滤示例。

示例1：过滤表示测量温度的设备的AE资源。

设备1 AE的语义描述符

设备2 AE的语义描述符

SPARQL请求1

SPARQL执行结果

(对于设备1语义描述)-->my:myDevice1

(对于设备2语义描述)-->empty

这意味着由my:myDevice1描述的AE资源将包括在结果集中，而由my:myDevice2描述的AE资源将不包括在内。

在一些情况下，用于单个搜索的相关语义信息可以分布在不同的<semanticDescriptor>资源中。图7中提供的示例说明了这种情况。方框表示语义过滤器的范围，即，这是评估它所需的信息。示出了表示主语-谓词-宾语关系的语义图，这个图的不同部分(由椭圆表示)存储在不同的<semanticDescriptor>资源中。语义过滤需要应用于完整的语义图(的部分)，这引发了必须将图的若干不同部分放在一起以执行语义操作的问题。

这个问题在语义Web领域中一般不明显，因为可以直接解除对识别类实例的URI的引用，因此可以基于其URI找到概念(即，类、关系)信息。在oneM2M情况下，只有可以被访问的资源及语义被存储为资源内容。

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

用于对跨越所提供的<semanticDescriptor>资源存储的语义描述启用语义过滤的解决方案以resourceDescriptorLink OWL注释特性的形式引入注释链接。可以为任何类实例指定这种注释特性，并且其值是<semanticDescriptor>资源的URL，其中可以找到用于给定类实例的附加RDF三元组。以下示例使用oneM2M Base Ontology中定义的类和关系(图8)，以创建图9中的图。

这种解决方案在接收者处为基于SPARQL的语义过滤引擎提供以下功能流程：1)对候选资源的语义描述符资源的内容执行公式化为SPARQL请求的语义过滤器；2)如果在执行过程中遇到具有一个或多个resourceDescriptorLink注释的类实例，那么执行被暂停；3)semanticDescriptorLink引用的每个<semanticDescriptor>资源的内容被添加到正在其上执行SPARQL请求的内容(延迟评估，替代方案：在执行之前获取所有内容，但可能导致获取不必要的信息)；4)继续对扩大的内容执行SPARQL请求；以及5)对数据资源和语义三元组的访问控制-分层次分层。

在本节中讨论了对作为语义三元组提供的语义信息的访问控制。当前的oneM2MTR-0007中支持本节中的内容。虽然当前的oneM2M体系架构视图完全基于资源，但这些可以以不同的方式实现。尤其是对于管理语义三元组，三元组存储装置是直截了当的选择。这对如何处理对资源和三元组的访问控制有影响。在本节中，假设在语义层和数据层之间划分的分层结构，讨论不同的实现选项。

如图10和图11中所示，数据资源和语义三元组可以集成在分层次分层体系架构中，具有包含数据资源和相关功能的数据层，以及包含语义三元组和相关语义功能的语义层。

上层(即，图10中的数据层和图11中的语义层)控制并管理访问控制策略(ACP)。下层(即，图10中的语义层和图11中的数据层)分别用语义图或原始数据支持上层。这些层可以驻留在不同的CSE上，但是在同一CSE上的集成可以更具性能效率。

图10示出了用于M2M场景的常规数据资源驱动的方案。通过数据资源树的资源发现可以由语义层中的语义叶子(例如，分布式图存储装置)支持。ACP维持在数据层中的<semanticDescriptor>资源下。

图11示出了用于语义Web场景的常规语义驱动的方案。可以在语义层中进行语义查询，其中返回数据层中的数据资源的URI或URL。还可以经由这两个层之间的适当映射返回数据层中的数据资源来实现语义资源发现。语义层中的三元组与其具体的ACP相关联。数据层中的数据资源由与ACP相关联的三元组(例如，经由其URI或URL)寻址。

对数据资源和语义三元组的访问控制-并行

超出当前支持的语义功能，可能需要更高级的体系架构。在下文中，引入了数据实体和语义实体的概念，它们可以在不同的配置中使用，从而支持更高级的语义功能，如语义混搭以及与语义web等其它语义平台的可能交互。

图12示出了用于智能IoT场景的示例性方案，其具有更高级的数据和语义特征或功能。如图12中所示，并行体系架构可以具有数据实体和语义实体。数据实体或语义实体可以各自具有其自己的访问控制策略(ACP)，用于在其范围内管理访问控制。数据实体中的语义三元组或数据资源可以通过相关联的具体ACP暴露给语义实体。例如，数据实体中的语义发布功能可以将语义三元组暴露给语义实体中的中心图存储装置，其中对应的ACP与三元组相关联。或者，例如，数据实体中的数据注释功能可以经由语义实体中的本地临时或高速缓存关系数据库管理系统(RDBMS)以及语义推理和映射功能将数据和相关联的ACP暴露给中心图存储装置。

语义实体中的数据资源或语义三元组也可以通过相关联的具体ACP暴露给数据实体。例如，语义实体中的语义混搭功能可以将新数据资源和相关ACP从语义混搭暴露给数据实体。或者，例如，语义实体中的语义标注功能可以将语义三元组和相关ACP暴露给数据实体中的<semanticDescriptor>资源。

图12示出了数据实体和语义实体可以驻留在不同的CSE上。但是数据实体和语义实体也可以驻留在同一个CSE上。图13示出了具有数据实体和语义实体的逻辑资源树。

经由资源树对集中式图存储装置的间接访问控制

另一种方法实际上是基于图存储装置的语义过滤。在这种方法中，访问控制将首先在oneM2M资源树上强制执行，以找到所有允许的<semanticDescriptor>资源；这个步骤将引入大量开销，因为将根据访问控制策略搜索所有<semanticDescriptor>资源。然后，允许的<semanticDescriptor>将被添加到SPARQL的查询模式中。之后，新的SPARQL将在语义图存储装置上执行。在这个解决方案中考虑一些假设：1)存在集中式图存储装置来存储所有<semanticDescriptor>中的三元组；以及2)基于资源树中具有目标URL或URI的查询请求，查询的范围仅限于作为目标URL下的子树中的子资源的<semanticDescriptor>中的三元组和链接到目标URL下的<semanticDescriptor>的相关<semanticDescriptor>。

在这个解决方案中，<semanticDescriptor>中的三元组将存储在图存储装置的一个图中。为了保留资源树中ACP的效果，<semanticDescriptor>用作锚点，以将资源树中的ACP链接到在语义存储库上查询期间使用的访问控制。这个解决方案的过程描述如下。

语义查询过程之前的预步骤：

1.托管图存储装置的CSE创建带有类SemanticDescriptor和atomDescription以及属性describedIn、hasSubject、hasObject和hasProperty的内部本体

2.对于(一个或多个)资源树中具有ACP的每个<semanticDescriptor>，托管图存储装置的CSE使用相应<semanticDescriptor>的IRI/URL在语义图存储装置中创建相应的语义描述符实例。语义描述符实例是预定义的类SemanticDescriptor的实例。

3.托管图存储装置的CSE在语义图存储装置中添加三元组，以将<semanticDescriptor>中的语义三元组与创建的语义描述符实例相关联。应当将其它CSE的(一个或多个)资源树中的<semanticDescriptor>中的三元组通知给托管图存储装置的CSE。考虑到可以在具有不同ACP的多个<semanticDescriptor>中描述一个主题，应当用每个三元组实现关联以用于分类，并且基于<semanticDescriptor>中描述的每个三元组来添加关联三元组。图14示出了三元组和语义描述符实例之间的关联。

例如，对于在<semanticDescriptor>中描述为“classX propertyY classZ”(S-P-O)的SD原始三元组，需要添加以下关联三元组(即，SD关系三元组)以定义这个SD原始三元组与<semanticDescriptor>资源之间的关系。

该过程在接收到具有SPARQL语句的语义查询请求之后。

1.接收者CSE基于资源树中的ACP和请求的目标URI来找出允许始发者(AE ID或CSE ID)用于查询的<semanticDescriptor>。

2.接收者CSE在语义图存储装置中识别对应的SemanticDescriptor实例(与<semanticDescriptor>相同的IRI/URL)。

3.在接收到的原始SPAQRL语义查询语句中，接收者CSE添加新句子以指示目标变量三元组与识别出的SemanticDescriptor实例相关联，如下：1)在SPARQL查询中找到变量及其相关三元组；2)用查询中的变量为每个三元组创建atomDescription变量；3)用查询中的变量将atomDescription变量与每个三元组相关联；并添加句子以将atomDescription变量和识别出的SemanticDescriptor实例相关联。图15示出了三元组与变量和SemanticDescriptor实例之间的关联。

例如，原始的SPAQRL查询是

如果在强制执行访问控制策略之后允许的SemanticDescriptor实例是SemanticDescriptor A，那么经修改的SPAQRL查询将作为以下给出

4.接收者CSE将经修改的SPARQL语义查询语句发送给托管图存储装置的CSE，以查询图存储装置。

5.接收者CSE基于从托管图存储装置的CSE接收的语义查询结果来编译响应。

经由集中式语义图存储装置对语义查询的直接访问控制

当作为语义查询的一部分执行SPARQL操作时，由<semanticDescriptor>的accessControlPolicylDs属性指示的<accessControlPolicy>可以用于语义图存储装置中的直接访问控制。一种现有方法是直接在语义图存储装置中实现访问控制策略，这使得控制对集中式语义图存储装置的访问更加高效和可扩展。这种方法包含以下主要步骤。

1)在语义图存储装置中构建由<accessControlPolicy>指定的访问控制规则。要注意的是，<accessControlPolicy>由<semanticDescriptor>资源的accessControlPolicylDs属性指定。

2)将作为目标的SD原始三元组(即，由<semanticDescriptor>的descriptor属性描述但存储在语义图存储装置中的RDF三元组)与其accessControlPolicylDs或具有相关访问控制规则的<accessControlPolicy>相关联。

3)使用所选择的语义三元组进行语义三元组操作，其中语义三元组与允许始发者操作的访问控制规则相关联。

下面的图16给出了用于两个<semanticDescriptor>资源的访问控制策略的示例，其中有两个访问控制策略(即，<accessControlPolicyl>和<accessControlPolicy2>)。对<semanticDescriptorl>的访问由<accessControlPolicyl>和<accessControlPolicy2>控制，而对<semanticDescriptor2>的访问仅由<accessControlPolicy2>控制。

提出了图17中所示的现有ACP本体，以基于oneM2M<accessControlPolicy>资源构造ACP三元组，其定义了两个新类：accessControlPolicy和accessControlRule。此外，还定义了五个新属性(即，hasACPRule、hasACOriginator、hasACOperations、hasACContexts和appliedTo)。hasACPRule用于将accessControlPolicy实例与accessControlRule实例链接。属性hasACOriginator、hasACOperations和hasACContexts(可选)基本上描述了accessControlRule实例并用于指定谁可以在哪些条件下发出什么操作。属性appliedTo用于描述可以向其应用accessControlPolicy实例的<semanticDescriptor>资源(即，绑定<accessControlPolicy>和<semanticDescriptor>)。要注意的是，这个本体是通过遵循如何在oneM2M-TS-0001中指定oneM2M<accessControlPolicy>资源来定义的，其中访问-控制-规则三元组由诸如accessControlOriginators、accessControlOperations和accessControlContexts之类的参数组成。

发明内容

oneM2M服务层提供<semanticDescriptor>资源以将三元组中的语义信息注释到常规资源。每个<semanticDescriptor>资源中的三元组可以存储在语义图存储装置(SGS)中。对oneM2M资源的访问控制由定义访问控制策略(ACP)的<accessControlPolicy>管理，而对SGS中三元组的访问可以通过向SGS添加附加的ACP三元组来直接控制。ACP三元组基本上对<accessControlPolicy>资源中定义的ACP建模。目前，如何将资源树中的<accessControlPolicy>与SGS中的ACP三元组同步仍然是个悬而未决的问题。本文公开了可以解决这些问题中的一些问题的方法、系统和装置，诸如增强的ACP本体、ACP三元组的管理，SD相关三元组的管理、ACP相关和SD相关三元组的基于代理服务器的管理，以及语义查询的性能。

对于增强的ACP本体，在现有ACP本体中为accessControlPolicy类公开新特性。这个新特性允许accessControlPolicy实例与个体SD原始三元组相关联。

关于管理ACP三元组，本文公开了用于维持托管CSE处的<accessControlPolicy>资源与SGS处的ACP三元组之间的同步的方法、系统和装置。在示例方法中，为了维持同步，托管CSE可以执行以下操作：1)当创建新<accessControlPolicy>资源时，托管CSE根据ACP本体生成新的ACP三元组，并将这些新的ACP三元组存储在SGS中；2)当更新现有<accessControlPolicy>资源的privileges属性时，托管CSE也生成新的ACP三元组并相应地更新SGS上对应的旧ACP三元组；以及3)当删除现有的<accessControlPolicy>资源时，如果SGS处有任何与所述被删除的<accessControlPolicy>资源相关的ACP三元组和ACP绑定三元组，那么托管CSE删除对应的ACP三元组和ACP绑定三元组。本文还预期仅在需要时创建或更新<accessControlPolicy>资源的ACP三元组。关于SD相关三元组的管理，包括何时以及如何创建/更新/删除ACP-SD三元组、SD关系三元组和SD原始三元组。

对于ACP相关和SD相关三元组的基于代理服务器(proxy)的管理，支持SPARQL并具有到SGS的接口的托管CSE可以充当其它托管CSE(其没有到SGS的接口)的代理服务器。这个托管CSE负责为这些其它托管CSE向SGS添加或更新ACP相关和SD相关的三元组。

对于语义查询的性能，当查询发起者(例如，oneM2M AE或CSE)向托管CSE发送语义查询请求时，托管CSE将这个语义查询请求(其可以是一个RESTful检索操作或SPARQL请求)转换成新的SPARQL请求。作为这种翻译的一部分，可以将查询发起者的标识符添加到新SPARQL请求的查询模式中。然后，托管CSE将新的SPARQL请求发送到SGS。

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

附图说明

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

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

图2图示了示例性分层数据库；

图3图示了oneM2M体系架构；

图4图示了oneM2M公共服务功能；

图5图示了<accessControlPolicy>资源的结构；

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

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

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

图9图示了示例性resourceDescriptionLink；

图10图示了由数据层控制的分层次分层结构中的访问控制；

图11图示了由语义层控制的分层次分层结构中的访问控制；

图12图示了并行结构中的访问控制；

图13图示了具有数据实体和语义实体两者的逻辑资源树；

图14图示了SD原始三元组与语义描述符实例之间的关联；

图15图示了SD原始三元组与SPARQL查询中的变量和SemanticDescriptor实例之间的关联；

图16图示了用于<semanticDescriptor>的访问控制策略的示例；

图17图示了现有的ACP本体；

图18图示了集中式语义图存储装置中的语义描述符；

图19图示了CSS中的示例性资源树与SGS中的三元组；

图20图示了存储在服务层处的示例性资源；

图21图示了存储在SGS中的示例性三元组；

图22图示了用于管理ACP三元组(和ACP-语义三元组)的示例性通用过程；

图23图示了用于管理语义三元组(和ACP-语义三元组)的示例性通用过程；

图24图示了用于在SGS中创建ACP三元组的示例性过程；

图25图示了用于<acp1>资源的示例性ACP三元组；

图26图示了用于在语义图存储装置中更新ACP三元组的示例性过程；

图27图示了用于删除SGS中的ACP三元组的示例性过程；

图28图示了用于更新<accessControlPolicy>资源的sdList属性的示例性过程；

图29图示了用于创建SD关系三元组和ACP-SD绑定三元组的示例性过程；

图30图示了示例性SD关系三元组；

图31图示了示例性ACP-SD绑定三元组；

图32图示了用于更新SGS中的ACP-SD绑定三元组的示例性过程；

图33图示了用于更新SGS中的SD关系三元组的示例性过程；

图34图示了用于从SGS删除SD关系三元组和ACP-SD绑定三元组的示例性过程；

图35图示了用于ACP相关和SD相关三元组的基于代理服务器的管理的示例性过程；

图36图示了用于在SGS中用访问控制执行语义查询的示例性过程；

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

图38图示了可以基于本文讨论的方法和系统生成的示例性显示(例如，图形用户界面)；

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

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

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

图39D图示了示例性计算系统，其中可以实施图39A的通信系统的各方面。

具体实施方式

本文公开了用于语义查询、访问控制策略同步和语义查询的访问控制。总之，讨论了以下主题：1)用于访问控制策略(ACP)本体的accessControlPolicy类的属性，其允许将accessControlPolicy实例应用于单个语义描述符(SD)原始三元组；2)ACP三元组的管理，包括何时以及如何创建ACP三元组，更新ACP三元组或删除ACP三元组；3)SD相关三元组的管理，包括何时以及如何创建/更新/删除ACP-SD三元组，SD关系三元组和SD原始三元组；4)基于代理的ACP相关和SD相关三元组的管理；5)托管CSE，其具有到SGS的接口，并且可以作为其它CSE的代理，其可以不直接与SGS通信，以管理用于那些CSE的ACP相关和SD相关的三元组；6)转换为SPARQL请求的语义查询的性能。

表7提供了本文使用的常用术语的定义。

表7：术语

以下是与服务层中的访问控制策略(ACP)同步的方法、系统和装置相关联的环境的附加上下文。如图18中所示，RDF三元组(例如，语义描述符)形式的语义描述被存放在集中式RDF三元数据库(例如，语义图存储装置)中。例如，医生151和医生151的患者(例如，患者152和患者153)可以将他们的语义描述符存储到集中式RDF三元组存储装置或语义图存储装置150(SGS 150)中。医生151、患者152和患者153是可以由医生和患者相应各方访问并且特别受其控制的应用。如果患者允许医生151这样做，那么医生151可以对他的患者的语义描述符进行语义查询。如果医生151向患者152或患者153授予许可，那么患者152或患者153还可以对他们自己的语义描述符和医生151的一些语义描述符进行语义查询。医生151和患者152不能对彼此的语义描述符进行语义查询，如果没有授予许可的话。如果患者152或患者153授予许可，那么医生151可以更新或删除他的语义描述符和患者152或患者153的一些语义描述符。患者152或患者153也可以更新或删除他或她自己的语义描述符以及医生151的一些语义描述符，如果医生151授予许可的话。虽然图18中未示出，但是关于患者152和患者153的健康相关的真实数据将被维护在服务层(例如，M2M服务器中)；用于这些真实健康数据的ACP也存储在服务层中。当服务层中的ACP改变时，需要用新的ACP更新SGS 150，使得SGS 150将其维护的三元组的ACP与存储在服务层中的真实健康数据的ACP同步。

图19图示了在SGS中存储语义三元组的同时在公共服务实体(CSE)处维护资源树的常规配置。资源树包括各种资源，诸如<semanticDescriptor>和<accessControlPolicy>。<accessControlPolicy>定义访问<semanticDescriptor>资源的访问控制规则。存储在SGS中的语义三元组包括语义描述符(SD)原始三元组(来自<semanticDescriptor>资源)、SD关系三元组、ACP三元组以及ACP-SD绑定三元组。引入SD关系三元组，以促进经由资源树进行语义发现的间接访问控制，而ACP三元组和ACP-SD绑定三元组被提议用于语义发现的直接访问控制，如背景技术中所描述的。

虽然存在用于控制对语义三元组的访问的常规解决方案，但是现有的问题是如何在服务层和SGS之间实现ACP同步和其它ACP功能。本文更详细地讨论以下问题：1)何时以及如何在SGS处创建ACP三元组；2)何时以及如何在SGS处创建ACP绑定三元组；3)何时以及如何在SGS处更新ACP三元组；4)何时以及如何在SGS处更新ACP-SD绑定三元组；5)何时以及如何更新SGS中的SD关系三元组；或者6)何时以及如何在SGS处触发和执行语义查询。

图20图示了存储在服务层处的资源。服务层可以维护多种类型的资源，诸如常规资源161、语义资源162和ACP资源163。常规资源161是实现其它服务层功能并维护常规数据的资源。常规资源161可以通过将一个或多个语义资源162或ACP资源163添加为子资源或者将一个或多个语义资源162或ACP资源163的统一资源标识符(URI)添加为其属性来与一个或多个语义资源162或ACP资源163相关联。例如，如果常规资源161具有语义资源162作为其子资源，那么语义资源162基本上注释关于常规资源161的额外语义信息。除了直接添加语义资源162作为其子资源之外，常规资源161可以替代地添加指向语义资源162的链接(例如，添加语义资源162的URI作为常规资源161的属性)。类似地，常规资源161可以具有ACP资源163作为其子资源。然后，可以通过ACP资源163中描述的访问控制策略来控制对常规资源161的访问。代替直接添加ACP资源163作为其子资源，常规资源161可以替代地添加指向ACP资源163的链接(例如，添加ACP资源163的URI作为常规资源161的属性)。

继续参考图20，语义资源162是维护用于描述常规资源161的语义信息(例如，RDF三元组)的资源。语义资源162可以通过将一个或多个ACP资源添加为其子资源或者添加一个或多个ACP资源URI作为其属性来与一个或多个ACP资源相关联。例如，语义资源162可以具有ACP资源163作为其子资源。然后，访问语义资源162将由ACP资源163中描述的访问控制策略控制。代替直接添加ACP资源163作为其子资源，语义资源162可以替代地添加指向ACP资源163的链接(例如，添加ACP资源163的URI作为语义资源162的属性)。

例如，ACP资源163是定义用于访问常规资源161或访问语义资源162的访问控制策略的资源。ACP资源163还可以通过将一个或多个常规资源161或语义资源162添加为其子资源或将一个或多个常规资源161或语义资源162的URI添加为其属性来与一个或多个常规资源161或语义资源162相关联。例如，ACP资源163可以具有语义资源162作为其子资源。然后，访问语义资源162将由ACP资源163中描述的访问控制策略控制。代替直接添加语义资源162作为其子资源，ACP资源163可以替代地添加指向语义资源162的链接(例如，添加语义资源162的URI作为ACP资源163的属性)。

图21图示了可以基于这些服务层资源(例如，语义资源162或ACP资源163)生成一些三元组并存储在SGS 150中。基于ACP资源156生成ACP三元组164。换句话说，ACP三元组164可以用于对ACP资源163建模。语义三元组165来自语义资源162。此外，可以生成附加三元组(例如，语义三元组165)，用于描述语义资源162与其包括的每个三元组之间的关系。ACP-语义三元组166(例如，ACP-语义绑定三元组)用于描述ACP资源163或语义资源162之间的关系。ACP-语义三元组166可以描述哪些ACP资源163可适用于哪些语义资源162。

应该理解的是，执行本文所示步骤(诸如图22-图37)的实体可以是逻辑实体。这些步骤可以存储在诸如图39C或图39D所示的设备、服务器或计算机系统的存储器中并在其上执行。在示例中，下面关于M2M设备的交互的进一步细节，图24和29的ACP发起者172或SD发起者173可以驻留在图39A的M2M终端设备18上，而图24和图29的托管CSE 171和SGS 170可以驻留在图39A的M2M网关设备14上。CSE171和SGS 170可以驻留在M2M服务器上。

图22和图23图示了用于管理ACP相关三元组和语义相关三元组以实现服务层和SGS之间的同步的方法，如本文更详细地讨论的。语义相关三元组可以包括“语义三元组(例如，SD原始三元组)”、“SD关系三元组”和“ACP-SD绑定三元组”。“语义相关”三元组可以多于“语义三元组”。ACP相关三元组可以包括“ACP三元组”和“ACP-SD绑定三元组”。对在服务层处托管的ACP资源的操作触发在SGS中对ACP相关三元组的管理(例如，创建ACP相关三元组、更新ACP相关三元组或删除ACP相关三元组)。相反，对在服务层处托管的语义资源的操作触发在SGS中对语义相关三元组的管理(例如，创建语义相关三元组、更新语义相关三元组或删除语义相关三元组)。要注意的是，图22和图23中的SGS都可以被实现为另一个服务层或另一个服务层的特殊功能。SGS可以驻留在另一个服务层中，诸如作为其一部分或作为整体。

再次，图22图示了用于管理ACP三元组(和ACP-语义三元组)的一般过程。在步骤181处，服务层169从请求者168接收操作ACP资源的请求。请求者168可以是应用或另一个服务层。在第一场景中，步骤181的请求可以是创建新的ACP资源。步骤181的请求可以包括要创建的ACP资源的资源表示。在第二场景中，步骤181的请求可以是更新现有的ACP资源。于是，步骤181的请求可以包括要更新的现有ACP资源的属性值或子资源表示。在第三场景中，步骤181的请求可以是删除现有的ACP资源。于是，步骤181的请求可以包括要移除的现有ACP资源的标识符(例如，名称)或URI。

在步骤182处，服务层169处理来自步骤181的请求。如果请求是场景1(例如，上面提到的第一场景)，那么服务层169使用步骤181的资源表示来创建所请求的ACP资源。如果请求是场景2(例如，上面提到的第二场景)，那么服务层169使用步骤181的属性值或子资源表示来更新所请求的ACP资源。如果请求是场景3(例如，上面提到的第三场景)，那么服务层169更新由步骤181的其标识符或URI识别出的所请求的ACP资源。在步骤183处，服务层169可以向请求者168发送响应，以通知它步骤182的执行结果。在步骤184处，服务层169可以取决于场景(例如，场景1或场景2)创建新的ACP三元组。如果是场景1，那么生成ACP三元组以对在步骤182中创建的新ACP资源建模。如果是场景2，那么生成ACP三元组以对在步骤182中更新后的ACP资源建模。

继续参考图22，在步骤185处，如果ACP资源具有语义资源子资源或者如果ACP资源具有指向或引用语义资源的属性，那么服务层185可以为第一场景或第二场景创建新的ACP-语义三元组。在步骤186处，服务层169可以向SGS 170发送SPARQL查询。参考第一场景，步骤186中的SPARQL查询可以用于在SGS 170中添加新的ACP三元组(来自步骤184)或者添加新的ACP语义三元组(来自步骤185)。对于第二场景，步骤186中的SPARQL查询可以用于在SGS 170中更新ACP三元组(来自步骤184)并更新ACP语义三元组(来自步骤185)。对于第三场景，步骤186中的SPARQL查询可以用于在SGS 170中移除ACP三元组(来自步骤184)或移除ACP语义三元组(来自步骤185)。

在步骤187处，SGS 170处理步骤186中的SPARQL查询。因而，SGS 170将添加新的ACP三元组和新的ACP-语义三元组(场景1)、更新现有的ACP三元组和ACP-语义三元组(场景2)，或删除现有的ACP三元组和ACP-语义三元组(场景3)。在步骤188处，SGS 170向服务层169发送响应。响应可以包括步骤187的SPARQL执行结果。

图23图示了用于管理语义三元组(和ACP-语义三元组)的一般过程。在步骤191处，服务层169从请求者168接收操作语义资源的请求。请求者168可以是应用或另一个服务层。在第四场景中，步骤191的请求可以是创建新的语义资源。步骤191的请求可以包括要创建的语义资源的资源表示。在第五场景中，步骤191的请求可以是更新现有语义资源。于是，步骤191的请求可以包括要更新的现有语义资源的属性值或子资源表示。在第六场景中，步骤191的请求可以是删除现有的语义资源。于是，步骤191的请求可以包括要移除的现有语义资源的标识符(例如，名称)或URI。

在步骤192处，服务层169处理来自步骤191的请求。如果请求是场景4(例如，上面提到的第四场景)，那么服务层169使用步骤191的资源表示来创建所请求的语义资源。如果请求是场景5(例如，上面提到的第五场景)，那么服务层169使用步骤191的属性值或子资源表示来更新所请求的ACP资源。如果请求是场景6(例如，上面提到的第六场景)，那么服务层169更新由步骤191的其标识符或URI识别出的所请求的语义资源。在步骤193处，服务层169可以向请求者168发送响应，以通知它步骤192的执行结果。在步骤194处，服务层169可以取决于场景(例如，场景4或场景5)创建新的语义三元组。如果是场景4，那么可以生成对在步骤192中创建的新语义资源建模的语义三元组。如果是场景5，那么可以生成对步骤192中更新后的语义资源建模的语义三元组。

继续参考图23，在步骤195处，如果语义资源具有语义资源子资源或者如果语义资源具有指向或引用语义资源的属性，那么服务层195可以为第四场景或第五场景创建新的ACP语义三元组。在步骤196处，服务层169可以向SGS 170发送SPARQL查询。参考第四场景，步骤196中的SPARQL查询可以用于在SGS 170中添加新的语义三元组(来自步骤194)和添加新的ACP-语义三元组(来自步骤195)。对于第五场景，步骤196中的SPARQL查询可以用于在SGS 170中更新语义三元组(来自步骤194)和更新ACP语义三元组(来自步骤195)。对于第六场景，步骤196中的SPARQL查询可以用于从SGS 170中移除语义三元组(来自步骤194)和移除ACP-语义三元组(来自步骤195)。

在步骤197处，SGS 170处理步骤196中的SPARQL查询。因而，SGS 170将添加新的语义三元组和新的ACP-语义三元组(场景4)、更新现有的ACP三元组和ACP-语义三元组(场景5)，或删除现有的语义三元组和ACP-语义三元组(方案6)。在步骤198处，SGS 170向服务层169发送响应。响应可以包括步骤197的SPARQL执行结果。

以下讨论的是高级ACP本体。在oneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0中讨论的常规ACP本体中，它仅支持semanticDescriptor级别访问控制，这意味着同一semanticDescriptor中的所有SD原始三元组具有相同的访问控制策略，因为它将acp:accessControlPolicy类实例仅经由acp:appliedTo属性绑定到<semanticDescriptor>资源实例。

针对acp:accessControlPolicy类公开了新属性acp:appliedToTriple。以下内容有助于将这个新属性acp:appliedToTriple置于上下文中。

sd:sdOriginalTriple是用于定义单个SD原始三元组的本体类。acp:accessControlPolicy是对oneM2M<accessControlPolicy>资源建模的本体类。利用这个新属性(例如，acp:appliedToTriple)，<semanticDescriptor>中的每个SD原始三元组可以分开绑定到acp:accessControlPolicy类实例。这个特征允许在SGS中强制执行访问控制，以便处理来自不同<semanticDescriptor>资源的语义三元组的语义查询。换句话说，这个新属性有助于实现更精细的粒度，使得不同的ACP可以应用于<semanticDescriptor>中的不同三元组(例如，三级ACP)。再次，常规上服务层可以应用于SD(其可以包括第一三元组和第二三元组)，但是现在如本文所述，服务层可以将ACP应用于具有更精细粒度的三元组。

以下是关于管理ACP三元组的考虑因素。图24图示了当ACP发起者请求在托管CSE处创建<accessControlPolicy>资源时在SGS中创建ACP三元组的方法。在步骤201处，ACP发起者172向托管CSE发送“Create<accessControlPolicy>resource”请求。这个消息包括要创建的<accessControlPolicy>的表示(例如，privileges属性的值)。在步骤202处，托管CSE 171接收步骤201的请求，并检查ACP发起者创建资源的访问权限。如果是允许的，那么托管CSE 171将相应地创建所请求的<accessControlPolicy>资源(称为<acp1>)。

与步骤202相关联的假设包括以下内容。假设创建的<accessControlPolicy>的URI是“acp1URI”。而且，假设<acp1>的privileges属性仅具有一个访问控制规则(称其为acrl 1)，并且访问privileges属性的URI是“acrl 1URI”，但是privileges属性可以包括多个访问控制规则。图25图示了用于<acp1>资源的ACP三元组的示例。对于这个示例，假设acrl允许AE(其ID为“AE-ID-1”)执行DISCOVERY操作。在步骤203处，托管CSE 171向ACP发起者发送响应，以通知它是否成功执行了步骤201中的请求。如果成功，那么“acp1URI”将包括在步骤203的响应消息中。

在步骤204处，基于步骤202中创建的<acp1>资源及ACP本体，托管CSE 171生成对应的ACP三元组。步骤204的生成的ACP三元组应当能够充分描述<accessControlPolicy>的privileges属性中包含的每个ACP规则，并且还应当能够描述每个ACP规则与<accessControlPolicy>资源之间的关联。图25中图示了用于在步骤201中创建的<acp1>资源的ACP三元组的示例。在图25中，第l行上的三元组简单地将前缀“acp”定义为示例。前缀“acp”在第2行-第6行中使用。在图25中，第2行上的三元组为步骤2中创建的<acp1>资源定义新的acp:accessControlPolicy类实例。这个三元组的主语值(即，acp:acp1)是基于步骤2中的假设的“acp1URI”。换句话说，基于这个三元组的主语值，有可能定位对应的资源<acp1>。而且，托管CSE 171可以使用“acp1URI”来定位SGS 170中的对应三元组；当托管CSE171需要更新现有的ACP三元组时需要这样做。基本上，与acp1相关的ACP三元组存储在SGS中并与acp1的URI(例如，acp1URI)相关联。因此，如果托管CSE171知道acp1的URI(例如，acp1URI)，那么它可以使用它来查找与这个URI对应的所有ACP三元组。因此可以存在对URI的搜索。

在图25中，第3行上的三元组定义acp:acp1实例具有相关联的访问控制规则acrl1。基于步骤202中的假设，这个三元组的宾语值(即，acp:acrl 1)是“acrl 1URI”。换句话说，基于这个三元组的宾语值，可以定位<acp1>资源的对应privileges属性。而且，托管CSE171可以使用“acrl 1URI”来定位SGS 170中的对应三元组；当托管CSE 171需要更新现有的ACP三元组时需要这样做。在图25中，第4行上的三元组定义acp:acrl 1(即，第3行上的宾语)是acp:accessControlRule类实例。在图25中，第5行和第6行上的三元组给出了基于步骤202中的假设的acp:acrl的两个属性的值。基本上，第4行-第6行上的三元组定义访问控制规则acrl 1。如果<acp1>具有更多访问控制规则，那么将与第4行-第6行类似地定义附加的访问控制规则。

继续参考图24，在步骤205处，托管CSE 171可以将SGS 170的地址添加到在新属性中在步骤202中创建的<accessControlPolicy>资源(例如，<acp1>)。在步骤206处，托管CSE171发送将在步骤204中创建的ACP三元组存储到所选择的SGS 170的SPARQL请求。作为示例，图25中所示的ACP三元组可以包括在SPARQL请求中。在步骤207处，SGS 170接收SPARQL请求，对其进行处理并将ACP三元组保存到其图存储装置中。在步骤208处，SGS 170将响应发送回托管CSE 171，以确认在步骤206中的请求被成功执行。

应当理解的是，在oneM2M中，在<accessControlPolicy>资源的单个属性privileges中描述访问控制规则。换句话说，可以使用相同的URI(例如，“.../<accessControlPolicy>/privileges”)来访问这些访问控制规则。但是，在ACP本体中，每个访问控制规则被建模为具有不同URI的不同实例。解决这个问题的一种方式是将privileges属性URI的序列号(或类似的区分符)作为用于每个访问控制规则实例的新URI附加，这将在SGS 170中使用。例如，假设用于访问<accessControlPolicy>的privileges的URI是privilegesURI并且privileges定义了三个访问控制规则。于是，SGS 170中的ACP三元组中使用的每个访问控制规则的URI可以分别是privilegesURI/1、privilegesURI/2、privilegesURI/3。

图26图示了用于更新SGS 170中的ACP三元组的方法，其可以由ACP发起者172触发，以更新现有<accessControlPolicy>资源的privileges属性，或者由托管CSE 171直接触发。在这个示例中，ACP发起者172请求更新根据图24的方法创建的<acp1>资源的privileges属性。在步骤211处，ACP发起者172将“Update<accessControlPolicy>resource”发送到托管CSE 171。在这里，ACP发起者172旨在更新<acp1>资源的privileges属性，其中“DISCOVERY”和“RETRIEVE”作为新的accessControlOperations。要注意的是，与图24和图25相关联的privileges的accessControlOperations可以仅被视为“DISCOVERY”。在步骤212处，托管CSE 171使用在步骤211中给出的新privileges属性值来更新<acp1>资源。在步骤213处，托管CSE 171向ACP发起者172发送响应，以通知它在步骤211中所请求的更新是否成功。

在步骤214处，基于步骤211中给出的<acp1>资源的privileges属性的新值，托管CSE 171生成新的ACP三元组，以将这种改变反映到<acp1>资源的privileges属性。例如，托管CSE 171可以简单地添加新的三元组“acp:acrl 1acp:hasACOperations“RETRIEVE””。可替代地，托管CSE 171可以将图25中第6行上的三元组替换为新的三元组“acp:acrl 1acp:hasACOperations“DISCOVERY”，“RETRIEVE””。在步骤215处，托管CSE 171向SGS 170发送更新与<acp1>资源相关的现有ACP三元组以反映在步骤211中请求的改变的SPARQL请求。如步骤214中所述，有多个选项来实现这一点。如下所示，作为第一选项，托管CSE 171只添加新的三元组。SPARQL可以看起来如下所示：

在第二个选项中，托管CSE 171决定替换图25中的第6行。

SPARQL可以看起来如下所示：

在步骤216处，SGS 170处理接收到的步骤215的SPARQL请求并更新对应的ACP三元组。在步骤217处，SGS 170向托管CSE 171发送响应，以通知它是否成功执行了步骤215中的请求。

图27图示了用于删除SGS 170中的ACP三元组和ACP-SD绑定三元组的过程，其可以由ACP发起者172触发以删除现有的<accessControlPolicy>资源或者由托管CSE 171直接触发。在这个示例中，ACP发起者172请求删除根据图24的方法创建的<acp1>资源。在步骤221处，ACP发起者172向托管CSE 171发送“Delete<accessControlPolicy>Resource”以删除<acp1>资源。在步骤222处，托管CSE 171使用在步骤221中给出的新privileges属性值来更新<acp1>资源。在步骤223处，托管CSE 171向ACP发起者172发送响应，以通知它在步骤221中所请求的删除是否成功。在步骤224处，托管CSE 171向SGS 170发送删除与<acp1>资源相关的现有ACP三元组和ACP-SD绑定三元组的SPARQL请求。SPARQL可以看起来如下所示：

在步骤225处，SGS 170处理接收到的步骤224的SPARQL请求，并移除所请求的ACP三元组和ACP-SD绑定三元组。在步骤226处，SGS 170向托管CSE 171发送响应，以通知它是否成功执行了步骤224中的请求。

以下是可以帮助执行ACP三元组管理的其它方法、系统和装置。先前关于图24-图27讨论了在创建、更新或删除<accessControlPolicy>资源时如何创建、更新或删除ACP三元组。当对<accessControlPolicy>资源的这种操作频繁时，对应的ACP三元组管理(例如，创建、更新或删除)会造成SGS 170的高开销。如果没有经由<semanticDescriptor>的accessControlPolicylDs属性与<accessControlPolicy>资源关联的<semanticDescriptor>资源，那么也可能是不必要的。所公开的属性(例如，syncFlag、syncTime、sdList)和更新属性的方法以及本文更详细讨论的其它方法可以帮助减轻频繁和不必要的ACP三元组管理。

syncFlag指示<accessControlPolicy>的对应ACP三元组已经存储在SGS 170中并与SGS 170同步(例如，如果syncFlag＝1)或者不(例如，如果syncFlag＝0)。syncTime指示这个<accessControlPolicy>的ACP三元组与SGS 170同步的最后时间。sdList指示可以满足以下条件的<semanticDescriptor>资源的列表：1)它们的accessControlPolicylDs属性指向这个<accessControlPolicy>资源；或者2)它们对应的SD原始三元组或SD关系三元组已经存储在SGS 170中。

托管CSE 171动态地更新每个<accessControlPolicy>资源的这三个属性的值。<accessControlPolicy>资源的syncFlag属性的默认值是0(即，FALSE)。当这个<accessControlPolicy>资源的ACP三元组存储到SGS 170并与SGS 170同步时，syncFlag属性的值可以改变为1(即，TRUE)。每次<accessControlPolicy>更新时，托管CSE 171首先将syncFlag改变为0(即，FALSE)。在将其新的ACP三元组存储到SGS 170并与SGS 170重新同步之后，可以再次将syncFlag改变为1(即，TRUE)。

<accessControlPolicy>资源的syncTime属性的默认值是零。在<accessControlPolicy>资源的ACP三元组已经与SGS 170同步(例如，在时间t1)之后，这个<accessControlPolicy>资源的syncTime属性可以被设置为t1。

在这里，<semanticDescriptor>资源的SD原始三元组或SD关系三元组已经存储在SGS 170中。在设置这个<semanticDescriptor>资源的accessControlPolicylDs(或者它使用其父资源的accessControlPolicylDs或任何系统默认<accessControlPolicy>)的任何时候，这个<semanticDescriptor>资源可以添加到对应的<accessControlPolicy>资源的sdList属性，如accessControlPolicylDs(或其父资源的accessControlPolicylDs)所表示的。在移除这个<semanticDescriptor>资源的accessControlPolicylDs或将其改变为空的任何时候，可以从对应的<accessControlPolicy>资源的sdList属性中移除这个<semanticDescriptor>资源，如accessControlPolicylDs所表示的。当更新这个<semanticDescriptor>资源的accessControlPolicylDs时，可以从旧<accessControlPolicy>资源的sdList属性中的列表中移除这个<semanticDescriptor>资源，并在新创建时将其添加到<accessControlPolicy>资源的sdList属性中。

下面更详细地讨论托管CSE 171基于syncFlag、syncTime或sdList属性动态管理ACP三元组。当第一次创建<accessControlPolicy>时，托管CSE 171不能在SGS 170中创建或存储对应的ACP三元组。如果是这样，那么托管CSE 171仅设置其syncFlag＝0、syncTime＝0和sdList＝empty。当在时间t2更新<accessControlPolicy>时，托管CSE 171可以执行以下操作：1)如果sdList为空，那么什么都不做并设置syncFlag＝0；或者2)如果sdList不为空并且syncTime大于零但小于t2，那么托管CSE 171可以使用与图26相关联的方法来更新SGS 170中的ACP三元组。然后设置syncFlag＝1和syncTime＝t2。当<accessControlPolicy>资源的sdList属性从“empty”变为“non-empty”时，托管CSE 171可以执行以下操作：1)如果syncFlag＝1，那么什么都不做；或者2)如果syncFlag＝0，那么托管CSE 171可以使用与图24或图25相关联的方法为这个<accessControlPolicy>资源创建ACP三元组并将它们存储到SGS 170。在这里，托管CSE 171在时间t3完成这个操作，然后syncFlag＝l和syncTime＝t3。

<accessControlPolicy>资源的SyncFlag属性和syncTime属性由托管这个<accessControlPolicy>资源的托管CSE 178更新。但是这个<accessControlPolicy>的sdList属性可以在不同情况下被更新，诸如以下所述。在第一种情况下，如果使用这个<accessControlPolicy>资源的<semanticDescriptor>资源也存储在这个托管CSE 178中，那么托管CSE 178负责更新sdList。在第二种情况下，如果使用这个<accessControlPolicy>资源的<semanticDescriptor>资源存储在托管CSE-B中，那么托管CSE-B向托管CSE 178发送更新这个<accessControlPolicy>资源的sdList属性的请求(图28)。

图28图示了在上面提到的第二种情况的上下文中更新<accessControlPolicy>资源的sdList属性的示例性方法。在这个示例中，给出以下内容：1)CSE 179托管<semanticDescriptor>资源(称为<sd1>)；2)CSE 178托管<accessControlPolicy>资源(称为<acp1>)；3)CSE 177托管<accessControlPolicy>资源(称为<acp2>)。在步骤231处，在时间t4，创建<sd1>资源并将其accessControlPolicylDs属性设置为<acp1>资源。在步骤232处，CSE 179向CSE 178发送更新<acp1>资源的sdList属性的请求。在步骤233处，CSE 178相应地更新<acp1>资源的sdList属性并且将响应发送回CSE 179。该响应通知CSE 179已经接收并处理了请求232，以及处理的结果(例如，成功或失败等)。在步骤234处，在时间t5，<sd1>的accessControlPolicylDs属性从<acp1>改变为<acp2>。因而，应当从<acp1>的sdList中移除<sd1>(步骤235)并将其添加到<acp2>的sdList(步骤237)。在步骤235处，CSE 179向CSE 178发送从<acp1>的sdList属性中移除<sd1>的请求。在步骤236处，CSE 178从<acp1>的sdList属性中移除<sd1>并向CSE 179发送响应。响应通知已经接收并处理了请求，以及处理的结果(例如，成功或失败等)。在步骤237处，CSE 179向CSE 177发送将<sd1>添加到<acp2>的sdList属性的请求。在步骤238处，CSE 177将<sd1>添加到<acp2>的sdList属性并向CSE 179发送响应。响应通知已经接收并处理了请求，以及处理的结果(例如，成功或失败等)。

以下是关于管理(例如，创建、更新、删除)与<semanticDescriptor>资源相关的三元组的考虑因素。图29图示了与在SGS中创建ACP-SD绑定三元组和SD关系三元组相关联的示例性方法。图30图示了SD关系三元组的示例。在图29中，SD发起者173(例如，oneM2M AE或CSE)请求在托管CSE 171处创建新的<semanticDescriptor>资源。在检查访问权限和其它相关的安全性功能之后，托管CSE 171本地创建<semanticDescriptor>资源(称为SD1及其URI，在这里被识别为sd1URI)。然后，托管CSE 171将如SD1资源的描述符属性中所描述的语义三元组存储到SGS 170。要注意的是，托管CSE 171生成新的SD关系三元组和ACP-SD绑定三元组并且也将它们存储到SGS 170。要注意的是，如果SD1没有accessControlPolicylDs属性，那么不会生成ACP-SD绑定三元组。由此，参考图29，在步骤241处，SD发起者173向托管CSE 171发送“Create<semanticDescriptor>Resource”请求。在这里，在请求消息中给出了<semanticDescriptor>资源的descriptor属性和accessControlPolicylDs属性的值。在这个示例中，描述符属性仅包括一个SD原始三元组“S1P1 01”。在这里，S1是这个三元组的主语，P1是这个三元组的谓词，O1是这个三元组的宾语。此外，accessControlPolicylDs的值是“acp1URI”(与本文的图24和图25相关联)。换句话说，访问控制策略acp1适用于控制对这个<semanticDescriptor>资源的访问。

继续参考图29，在步骤242处，托管CSE 171相应地创建<sem anticDescriptor>资源(称为sd1)。sd1的URI是sd1URI。在步骤243处，托管CSE 171向SD发起者173发送响应，以通知它是否成功创建了步骤241中所请求的<semanticDescriptor>资源。在步骤244处，根据sd1的描述符属性中包括的SD原始三元组，托管CSE 171生成SD关系三元组。根据步骤241，只有一个SD原始三元组。因而，生成图30中所示的SD关系三元组。在步骤245处，由于sd1的accessControlPolicylDs属性指向acp1资源，因此托管CSE 171生成ACP-SD绑定三元组，如图31中所示。图31的第5行示出SGS 170中的访问控制策略“acp:acp1”适用于SGS 170中的语义描述符“sd:sd1”。在步骤245处，托管CSE 171向SGS 170发送将这些SD关系三元组和ACP-SD绑定三元组存储到SGS 170的SPARQL请求。在步骤248处，SGS 170向托管CSE 171发送响应消息，以通知它步骤246中的SPARQL请求是否成功执行。在图29的上下文中，在步骤242中创建的<semanticDescriptor>资源sd1可能没有设置accessControlPolicylDs属性或者其accessControlPolicylDs属性不与有效的<accessControlPolicy>资源对应。在这种情况下，如果使用sd1的父资源的accessControlPolicylDs属性，那么还将使用其父资源的accessControlPolicylDs属性生成新的ACP-SD绑定三元组。如果应用系统默认访问权限，那么将基于这个默认特权生成新的ACP-SD绑定三元组。

图32图示了当<semanticDescriptor>资源的accessControlPolicylDs属性改变时与更新ACP-SD绑定三元组相关联的示例性方法。在这个示例中，与图29相关联地创建的sd1资源的accessControlPolicylDs从acp1改变为另一个<accessControlPolicy>资源(称为acp2)。而且在这个示例中，用于资源acp2的ACP三元组已创建如下：

参考图32，在步骤251处，SD发起者173发送将资源sd1的accessControlPolicylDs从资源acp1的URI更新为资源acp2的URI的请求。资源acp2的URI(例如，acp2URI)包括在这个请求中。资源sd1的URI(即，sd1URI)也包括在步骤251的请求中。在步骤252处，托管CSE171检查访问权限。如果这被允许，那么托管CSE 171用步骤251中给出的acp2的URI更新sd1的accessControlPolicylDs。在步骤253处，托管CSE 171将响应发送回SD发起者173，以通知它步骤251的请求是否成功。在步骤254处，由于sd1的accessControlPolicylDs被改变，因此托管CSE 171生成新的ACP-SD绑定三元组(“acp:acp2acp:appliedTo sd:sd1”)以反映这种改变。这个新的ACP-SD绑定三元组将取代旧的ACP-SD绑定三元组(例如，“acp:acp1acp:appliedTo sd:sd1”)

o(新的ACP-SD绑定三元组)acp:acp2acp:appliedTo sd:sd1

o(旧的ACP-SD绑定三元组)acp:acp1acp:appliedTo sd:sd1

在步骤255处，托管CSE 171发送用新的ACP-SD绑定三元组替换SGS 170中的旧ACP-SD绑定三元组的SPARQL请求，如上面步骤254所示。这个SPARQL请求可以看起来如下所示：

在步骤256处，SGS 170处理SPARQL请求并更新在步骤5中指定的ACP-SD绑定三元组。在步骤257处，SGS 170向托管CSE 171发送响应，以通知它步骤255中的SPARQL请求是否成功执行。应当理解的是，参考图32，如果<semanticDescriptor>资源的accessControlPolicylDs属性开始为空，那么应当强制执行其父资源的accessControlPolicylDs。托管CSE对此保持跟踪并根据父资源的accessControlPolicylDs属性的更新应用这个步骤。

图33图示了当<semanticDescriptor>资源的描述符属性改变时与更新SD关系三元组相关联的示例性方法。在这个示例中，与图29相关联地创建的sd1资源的描述符被改变为具有两个SD原始三元组(旧的一个-“S1P1O1”；新的一个-“S2P2O2”)。要注意的是，也可以通过用SPARQL查询来定位<semanticDescriptor>父资源的semanticOpExec属性来执行描述符属性中三元组的更新。当执行这个SPARQL查询时，可以将新的SD原始三元组添加到<semanticDescriptor>资源的descriptor属性。因而，执行图33的步骤264-步骤267。更具体而言，SPARQL Update可以包括DELETE或ADD操作，因此将删除与旧的原始三元组相关联的SD关系三元组，然后创建新的SD关系三元组以与新的原始三元组相关联。

参考图33，在步骤261处，SD发起者173发送更新资源sd1的描述符以包括一个新的SD原始三元组(即，“S2 P2 O2”)的请求。资源sd1的URI(例如，sd1URI)也可以包括在这个请求中。在步骤262处，托管CSE 171检查访问权限。如果这被允许，那么托管CSE 171通过添加一个新的SD原始三元组(即，“S2P2O2”)来更新sd1的描述符属性。在步骤263处，托管CSE171将响应发送回SD发起者173，以通知它步骤1中的请求是否成功。在步骤264处，由于sd1的描述符属性被改变，因此托管CSE 171生成下面的新SD关系三元组以反映这种改变。

在步骤265处，托管CSE 171发送在SGS 170中用步骤264中生成的新的SD关系三元组替换旧的SD关系三元组或者添加新的SD关系三元组的SPARQL请求。这个SPARQL请求可以看起来如下所示，其中托管CSE 171只添加新的三元组。

在步骤266处，SGS 170处理SPARQL请求并添加步骤265中包括的新SD关系三元组。在步骤267处，SGS 170向托管CSE 171发送响应，以通知它是否成功执行步骤265中的SPARQL请求。要注意的是，如果旧的SD原始三元组被移除或用新的SD原始三元组更新，那么与旧的SD原始三元组相关的对应SD关系三元组将从SGS 170中被移除。

图34图示了用于从SGS 170删除SD关系三元组和ACP-SD绑定三元组的示例性方法，该方法可以由发起AE/CSE或托管CSE 171触发以删除<semanticDescriptor>资源。在这个示例中，移除了与图29相关联地创建的sd1资源。要注意的是，<semanticDescriptor>资源的semanticOpExec属性包括SPARQL查询；如果执行这个SPARQL查询，那么可以从<semanticDescriptor>资源的descriptor属性中删除现有SD原始三元组；因而，将执行图34的步骤274-步骤276。

在步骤271处，SD发起者173向托管CSE 171发送“Delete<semanticDescriptor>Resource”以删除sd1资源。Sd1资源的URI(例如，sd1URI)包括在这个请求中。在步骤272处，托管CSE 171在本地删除sd1资源。在步骤273处，托管CSE 171向SD发起者173发送响应，以通知它步骤271中的删除请求是否成功。在步骤274处，托管CSE 171向SGS 170发送移除与sd1资源相关的SD关系三元组和ACP-SD绑定三元组的SPARQL请求。SPARQL可以看起来如下所示：

在步骤275处，SGS 170处理步骤274中的SPARQL请求并移除对应的SD关系三元组和ACP-SD绑定三元组。在步骤276处，SGS 170向托管CSE 171发送响应，以通知它是否成功执行了步骤274中的SPARQL请求。

图35图示了ACP相关和SD相关三元组的基于代理服务器的管理的示例性方法。有时，托管CSE 171不能支持SPARQL接口，这使得难以与SGS 170执行直接交互。相反，这个托管CSE 171可以充分利用可以直接与SGS 170交互以代表它管理ACP相关三元组和SD相关三元组的其它托管CSE 171。图35图示了这样的示例，其中：1)托管CSE 171支持SPARQL接口并且与SGS 170直接交互；2)托管CSE 174不支持SPARQL接口并且不能直接与SGS 170讲话；以及3)托管CSE 174充分利用托管CSE 171作为代理服务器来管理与在托管CSE 174处托管的<accessControlPolicy>或<semanticDescriptor>资源相关的ACP相关和SD相关三元组。

参考图35，在步骤281处，托管CSE 171向托管CSE 174发送“ACP/SD订阅请求”。如果存在对在托管CSE 174处托管的<accessControlPolicy>或<semanticDescriptor>消息的改变，那么应当向托管CSE 171发送自动通知。在步骤282处，对<accessControlPolicy>或<semanticDescriptor>资源进行改变。在步骤283处，托管CSE 174向托管CSE 171发送“ACP/SD通知”。这个消息包括对<accessControlPolicy>或<semanticDescriptor>资源的改变。例如，它可以是新<accessControlPolicy>的表示、<accessControlPolicy>的privileges属性的新值、新<semanticDescriptor>的表示，或<semanticDescriptor>的descriptor属性的新值。在步骤284处，取决于在步骤283接收哪些改变，托管CSE 171生成一些新的三元组(例如，新的ACP三元组、新的ACP-SD绑定三元组、新的SD关系三元组或新的SD原始三元组)。本文已经讨论了关于管理ACP三元组和管理SD相关三元组的细节。

继续参考图35，在步骤285处，托管CSE 171生成将这些来自步骤284的新三元组添加到SGS 170中或者使用它们替换SGS 170中的对应旧三元组的SPARQL消息。本文已经讨论了关于管理ACP三元组和管理SD相关三元组的细节。在步骤286处，托管CSE 171将来自步骤285的SPARQL消息发送到SGS 170。在步骤287处，SGS 170处理接收到的SPARQL消息。在步骤288处，SGS 170向托管CSE 171发送响应。响应通知托管CSE 171是否成功执行了步骤286中的SPARQL请求。

图36图示了用于用访问控制对SGS执行语义查询的示例性方法。在步骤291处，查询发起者175(例如，oneM2M AE或CSE)向托管CSE 171发送SPARQL请求或包括SPARQL请求的RESTful检索操作。在这个示例中，考虑以下内容：1)步骤的请求291针对“DISCOVERY”操作；以及2)查询发起者175是oneM2M AE，并且其标识符是“AE-ID-1”。查询发起者175的标识符包括在步骤291的这个请求消息中。步骤291的请求可以包括新参数sparqlType，以指示这个请求是：1)直接发现包括在<semanticDescriptor>资源中的三元组或信息(例如，sparqlType＝1)；还是2)间接发现子资源<semanticDescriptor>满足SPARQL请求中的查询模式的资源(例如，sparqlType＝2)。

继续参考图36，在步骤292处，托管CSE 171从在步骤291接收到的请求中提取SPARQL查询消息。在步骤293处，托管CSE 171基于包括在步骤291中的查询发起者175的标识符生成以下ACP查询模式。

在步骤294处，托管CSE 171将ACP查询模式添加到在步骤292中提取出的SPARQ消息。如果步骤291中的请求是RESTful操作，那么托管CSE 171一般将来自步骤291的RESTful操作消息转换为标准SPARQL信息。在本文应该理解的是，如果没有进行步骤293和步骤294，那么SGS可能不知道哪个SPARQL查询来自哪个发起者。如果跳过了步骤293和294，那么在步骤295中将发送原始SPARQL请求，因此SGS 170不知道这个查询来自哪个发起者，然后它不能强制执行正确的访问控制策略。

在步骤295处，托管CSE 171将新的SPARQL消息发送到SGS 170。在步骤296处，SGS170处理并执行接收到的SPARQL消息。在步骤297处，SGS 170将具有查询结果的响应发送到托管CSE 171。如果步骤291中的sparqlType指示步骤291中的请求是发现资源，那么查询结果包括<semanticDescriptor>资源的列表。否则，查询结果包括所选择的变量的值，如步骤291中包括的SPARQL消息的SELECT结果子句中所示。

在步骤298处，如果步骤1中的sparqlType指示步骤291中的SPARQL请求是间接发现资源(例如，sparqlType＝2)，那么步骤297中的“查询结果”是<semanticDescriptor>资源的URI列表。然后，可能需要这个步骤298让托管CSE 171定位这些<semanticDescriptor>资源的父资源。这些父资源的URI可以包括在步骤299的响应中。在这个步骤298中，托管CSE171将在步骤297中接收到的响应转换为步骤291中的请求的响应消息。在步骤298中，托管CSE 171 1)定位在步骤297中作为查询结果返回的<semanticDescriptors>资源的父资源；或者2)简单地接受步骤297中的查询结果。要做的动作可以取决于步骤291中包含的sparqlType参数。步骤291中的请求的响应消息的格式可以与在步骤297中接收到的响应的格式不同。在步骤299处，托管CSE 171将结果作为对步骤291中的请求的响应发送给查询发起者175。结果可以包括以下之一：1)如果执行步骤298，那么在步骤298中识别出的父资源列表；或者2)如果不执行步骤298，那么包括在步骤297中的查询结果。图36的这个方法的实现选项可以使用由sparqlType提供的信息，如下：1)如果在步骤291中sparqlType＝1，那么托管CSE 171将其发送到SGS 170以作为查询进行处理，如图36中所示；或者2)如果在步骤291中sparqlType＝2，那么托管CSE 171可以替代地在步骤291中处理请求消息，作为基于资源树中的直接访问控制的发现，而不联系SGS 170。

以下是考虑oneM2M的附加示例。表8提供了可以使用的三个属性，这些属性在本文中更详细地讨论。

表8.<accessControlPolicy>资源的新属性

对于oneM2m，可以存在新的请求参数，诸如sparqlType。sparqlType被提议作为新参数，它可以包括在oneM2M请求消息中。sparqlType指示这个请求中包括的SPARQL消息是发现oneM2M资源还是查询<semanticDescriptor>资源中包含的三元组和相关信息。在请求消息包括SPARQL消息的任何时候，sparqlType也可以包括在请求中。作为示例，sparqlType的值可以设置如下：

·sparqlType＝0：基于其子资源<semanticDescriptor>中包括的语义信息发现oneM2M资源。

·sparqlType＝l：发现<semanticDescriptor>资源中包括的语义信息。

图37图示了用于发起AE/CSE(发起者301)、托管CSE 302和SGS 303的示例性用户界面。发起者301(例如，ACP发起者172、SD发起者173)的用户界面被设计为显示发送给托管CSE 302的请求，如方框311中所示。对于发送的每个请求，可以显示所示参数。参数“hosting CSE”示出托管CSE 302的地址，参数“Action”示出请求所表示的动作(例如，创建<accessCotrolPolicy>资源、更新<accessControlPolicy>资源、删除<accessControlPolicy>资源、创建<semanticDescriptor>资源、更新<semanticDescriptor>资源的descriptor属性、更新<semanticDescriptor>资源的accessControlPolicylDs属性、删除<semanticDescriptor>资源)。

继续参考图37，托管CSE 302的用户界面312可以被设计为显示从发起者301接收的请求。对于发送的每个请求，可以显示如方框312中所示的参数。参数“Requestor”代表发起者301的地址，并且参数“Action”示出请求表示的动作(例如，创建<accessCotrolPolicy>资源、更新<accessControlPolicy>资源、删除<accessControlPolicy>资源、创建<semanticDescriptor>资源、更新<semanticDescriptor>资源的descriptor属性、更新<semanticDescriptor>资源的accessControlPolicylDs属性、删除<semanticDescriptor>资源)。SGS 170的用户界面313可以被设计为在图中示出ACP相关和SD相关三元组之间的关系。

图38图示了可以基于本文讨论的方法和系统生成的示例性显示(例如，图形用户界面)。显示器接口901(例如，触摸屏显示器)可以在方框902中提供与访问控制策略同步或本文所讨论的其它语义事项相关联的文本，诸如表7和表8的参数。在另一个示例中，本文讨论的任何步骤的进展(例如，发送的消息或步骤的成功)都可以在方框902中显示。此外，图形输出903可以显示在显示器接口901上。图形输出903可以是访问控制策略同步中设备的拓扑或其它本文讨论的语义事项，或本文讨论的任何方法或系统的进展的图形输出，等等。

在不以任何方式不当地限制本文出现的权利要求的范围、解释或应用的情况下，本文公开的一个或多个示例的技术效果是提供如本文所公开的语义ACP同步。语义ACP同步(也被公开为语义ACP同步)是将语义功能引入M2M/IoT服务层时可能发生的新问题。因此，这在常规系统(例如，常规语义系统或常规M2M/IoT服务层)中一般不是问题。所公开的语义ACP同步使得能够在执行语义操作的同时在语义三元组存储装置中进行直接访问控制，这可以比在语义三元组存储装置中首先操作语义操作、然后在M2M/IoT服务层上强制执行访问控制更高效和更好(例如，就由于访问控制引起的结果执行时间而言)。另外，在常规的M2M/IoT服务层中，在其服务层资源树上而不是在语义三元组存储装置上强制执行访问控制。因此，常规上，当在语义三元组存储装置中执行语义操作时，对应的服务层访问控制策略不能被强制执行，并且实际上可以被违反，这意味着可以访问存储在语义三元组存储中的三元组，但是根据服务访问控制策略，它们不应当被访问。常规系统可以依赖服务层资源树上的访问控制。

图39A是示例机器到机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图，其中可以实现与访问控制策略同步或其它语义事项相关联的一个或多个公开的概念(例如，图20-图38和随附的讨论)。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关或M2M服务平台都可以是IoT/WoT以及IoT/WoT服务层等的部件。

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

如图39A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域(FieldDomain)。基础设施域是指端到端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、蓝牙)、直接无线电链路和有线线路。

参考图39B，现场域中所示的M2M服务层22(例如，如本文所述的托管公共服务实体171)为M2M应用20(例如，SD发起者173或ACP发起者172)、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'可以由一个或多个服务器、计算机、虚拟机(例如，云/计算/存储装置场等)等实现。

还参考图39B，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功能实体)可以提供应用或服务。ETSI M2M和oneM2M都使用服务层，该服务层可以包括本申请在本文所讨论的访问控制策略同步或其它语义事项。oneM2M服务层支持公共服务功能(CSF)(即，服务能力)的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上托管。另外，本申请在本文所讨论的访问控制策略同步或其它语义事项可以被实现为M2M网络的一部分，该M2M网络使用面向服务的体系架构(SOA)或面向资源的体系架构(ROA)来访问诸如本申请在本文所讨论的访问控制策略同步或其它语义事项之类的服务。

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

例如，图39C是示例M2M设备30的系统图，诸如M2M终端设备18(其可以包括ACP发起者172或医生151)或M2M网关设备14(其可以包括托管CSE 171)。如图39C中所示，M2M设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50以及其它外围设备52。将认识到的是，M2M设备30可以包括前述元件的任意子组合，同时保持与所公开的主题一致。M2M设备30(例如，ACP发起者172、患者152、医生151、托管CSE 171等)可以是执行所公开的用于服务层中的访问控制策略同步或本文所讨论的其它语义事项的系统和方法的示例性实现。

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

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

此外，虽然发送/接收元件36在图39C中被描绘为单个元件，但是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)卡、记忆棒、安全数字存储卡等。在其它示例中，处理器32可以从物理地位于M2M设备30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为响应于在一些示例中本文所讨论的访问控制策略同步或其它语义事项是成功还是不成功(例如，更新访问策略控制资源)来控制显示器或指示器42上的照明图案、图像或颜色，或以其它方式指示本文讨论的服务层中的访问控制策略同步或其它语义事项和相关联组件的状态。显示器或指示器42上的控制照明图案、图像或颜色可以反映本文所示或讨论的图(例如，图18-图38等)中的任何方法流程或部件的状态。本文公开了本文讨论的访问控制策略同步或其它语义事项的消息和过程。可以扩展消息和过程，以便经由输入源(例如，扬声器/麦克风38、小键盘40或显示器/触摸板42)为用户提供请求与属性或资源或者服务层中的访问控制策略同步或本文所讨论的其它语义事项相关联的信息以及请求、配置或查询与本文所讨论的访问控制策略同步或其它语义事项相关联的信息的接口/API，以及可以在显示器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之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。

图39D是示例性计算系统90的框图，例如，可以在其上实现图39A和图39B的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连接到外部通信网络，诸如图39A和图39B的网络12。

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

在描述本公开的主题(服务层中的访问控制策略同步或本文所讨论的其它语义事项)的优选方法、系统或装置时，如图中所示，采用具体的术语是为了明晰。但是，所要求保护的主题并不旨在限于如此选择的具体术语，并且应当理解的是，每个具体元件包括以类似方式操作以实现类似目的的所有技术等同物。虽然在整个公开内容中提到了SPARQL请求等，但是本文预期可以使用相关联的RESTful操作。本文使用的术语仅仅是用于说明的目的，并且某些功能在将来的实现中可以具有不同的名称。

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

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

如本文所述的方法、系统和装置及其它可以提供用于服务层的访问策略同步的部件。方法、系统、计算机可读存储介质或装置具有用于执行以下操作的部件：接收由应用创建资源的请求消息，其中资源用于访问控制策略；基于应用具有创建资源的访问权限的确定而创建资源；基于资源和访问控制策略的本体，生成与资源和本体相关联的三元组；以及提供将三元组发送到语义图存储装置以供存储的指令。该方法、系统、计算机可读存储介质或装置具有用于提供向应用发送响应消息的指令的部件，该响应消息包括资源的统一资源标识符，其可以响应于或基于请求信息。该方法、系统、计算机可读存储介质或装置具有用于将语义图存储装置的地址添加到资源的部件。该方法、系统、计算机可读存储介质或装置具有用于将语义图存储装置的地址添加到资源的新属性的部件。请求消息包括要创建的资源的表示。该表示可以是privileges属性的值。资源可以包括privileges属性，其包括多个访问控制规则。资源可以包括syncFlag属性、syncTime属性或sdList属性。本段中的所有组合(包括步骤的移除或添加)都以与详细描述的其它部分一致的方式考虑。

如本文所述的方法、系统和装置可以提供用于服务层的访问策略同步的部件。方法、系统、计算机可读存储介质或装置具有用于执行如下操作的部件：从应用接收更新属性的请求消息，属性包括用于资源的第一访问控制策略标识符，其中资源是用于访问控制策略的；基于应用具有更新资源的访问权限的确定，更新资源以包括第二访问控制策略标识符而不是第一访问控制策略标识符；以及基于资源的更新，生成与访问控制策略和语义描述符相关联的新的绑定三元组。该方法、系统、计算机可读存储介质或装置具有用于提供在图形用户界面上显示应用的资源的状态的指令的部件。该方法、系统、计算机可读存储介质或装置具有用于从语义图存储装置接收确认在语义图存储装置上替换旧的绑定三元组的消息的部件。该方法、系统、计算机可读存储介质或装置具有用于提供在图形用户界面上显示应用的资源的状态的指令的部件。新的绑定三元组可以替换与第一访问控制策略标识符相关联的旧的绑定三元组。第一访问控制策略标识符可以由第一统一资源标识符指示。第二访问控制策略标识符可以由第二统一资源标识符指示。属性可以是语义描述符的属性。装置可以是托管公共服务实体。

Claims

1.一种用于服务层的访问策略同步的装置，该装置包括：

处理器；以及

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

接收由应用创建资源的请求消息，其中所述资源用于访问控制策略；

基于所述应用具有创建所述资源的访问权限的确定而创建所述资源；

基于所述资源和访问控制策略的本体，生成与所述资源和所述本体相关联的三元组；以及

提供将所述三元组发送到语义图存储装置的指令。

2.如权利要求1所述的装置，进一步的操作包括将语义图存储装置的地址添加到所述资源。

3.如权利要求1所述的装置，进一步的操作包括将语义图存储装置的地址添加到所述资源的新属性。

4.如权利要求1所述的装置，进一步的操作包括，基于所述请求消息，提供向所述应用发送响应消息的指令，所述响应消息包括所述资源的统一资源标识符。

5.如权利要求1所述的装置，其中所述请求消息包括要创建的所述资源的表示。

6.如权利要求1所述的装置，其中所述请求消息包括要创建的所述资源的表示，该表示是privileges属性的值。

7.如权利要求1所述的装置，其中所述资源包括privileges属性，该privileges属性包括多个访问控制规则。

8.如权利要求1所述的装置，其中所述装置是托管公共服务实体。

9.一种用于服务层的访问策略同步的方法，该方法包括：

提供将所述三元组发送到语义图存储装置的指令。

10.如权利要求9所述的方法，还包括，响应于接收到所述请求消息，提供向所述应用发送响应消息的指令，所述响应消息包括所述资源的统一资源标识符。

11.如权利要求9所述的方法，其中所述请求消息包括要创建的所述资源的表示。

12.如权利要求9所述的方法，其中所述请求消息包括要创建的所述资源的表示，该表示是privileges属性的值。

13.如权利要求9所述的方法，其中所述资源包括privileges属性，该privileges属性包括多个访问控制规则。

14.如权利要求9所述的方法，还包括将语义图存储装置的地址添加到所述资源。

15.如权利要求9所述的方法，还包括将语义图存储装置的地址添加到所述资源的新属性。

16.如权利要求9所述的方法，其中所述装置是托管公共服务实体。

17.一种存储计算机可执行指令的计算机可读存储介质，所述计算机可执行指令在由计算设备执行时使所述计算设备实现包括以下的操作：

提供将所述三元组发送到语义图存储装置的指令。

18.如权利要求17所述的计算机可读存储介质，进一步的操作包括将语义图存储装置的地址添加到所述资源。

19.如权利要求17所述的计算机可读存储介质，进一步的操作包括将语义图存储装置的地址添加到所述资源的新属性。

20.如权利要求17所述的计算机可读存储介质，进一步的操作包括，基于所述请求消息，提供向所述应用发送响应消息的指令，所述响应消息包括所述资源的统一资源标识符。