CN106663143B - M2m本体管理和语义互操作性 - Google Patents

Abstract

M2M本体处理器负责对从M2M域外部或内部发布的本体进行处理、存储或提供发现功能。M2M本体处理器可以在功能上由本体处理组件、本体分类组件、本体发现组件和本体储存库组成。本体处理组件可以处理M2M命名空间外部和内部的发布的本体，M2M命名空间可以用于向对象/实体提供语义信息。本体分类组件可以对本体进行分类并将其存储在本体储存库中的正确层级/位置中以用于发现和使用。本体发现组件可以提供本体发现并确定匹配的本体以供请求者使用。本体储存库可以存储在M2M域外部和内部发布或生成的任何本体模型。那些本体可以用于资源以实现语义。因此，本体储存库可以与本体分类组件和本体发现组件交互。

Description

M2M本体管理和语义互操作性

相关申请的交叉引用

本申请要求于2014年7月18日提交的名称为“M2M ONTOLOGY MANAGEMENT ANDSEMANTICS INTEROPERABILITY(M2M本体管理和语义互操作性)”的美国临时专利申请No.62/026569的权益，其内容通过引用并入本文。

背景技术

部署在物理环境中的启用网络的设备和传感器的数量的快速增加正在改变通信网络。据预测，在未来十年内，数十亿台设备将针对由在智能电网、智能家居、电子健康、汽车、运输、物流和环境监视等的各种领域内的服务提供商的应用和服务而生成大量的真实世界数据。使得能够将现实世界数据和服务集成到当前信息网络技术中的相关技术和解决方案通常在物联网(IoT)或机对机(M2M)通信的涵盖性术语下进行描述。由于设备创建的大量数据，需要有效的方式来识别和查询此数据。

图1图示了可由患者的医院或康复中心使用利用致动器作为聚合点的紧凑生物医学无线传感器微粒而提供的示例性患者监视应用。致动器将数据发送到网络。这些小的可佩戴资源受限设备是可以部署在患者上以连续监视诸如血压和血流、核心温度、氧饱和度、运动、心率、听力和视觉等生命体征的M2M设备的示例。如图1所示，由M2M设备收集的各种类型的M2M数据可以由患者的医生、私人教练(例如来自24小时健身)和/或救护车服务使用。为了使医生、私人教练和救护车服务使用从那些M2M设备生成的数据，这些资源的语义也需要是可用的。语义提供数据的描述性定义，使得可以理解数据的格式和结构(即，语义提供数据的含义)。

M2M语义支持旨在实现原始资源的语义以用于对它们的通用理解/解释，以及对它们的任何高级处理，例如语义查询、数据分析等。在背景部分中引入现有的在语义Web中开发的技术和在不同命名空间中开发的现有本体。此外，介绍了oneM2M架构和服务层。

语义Web中的现有技术

语义Web使用模式语言和本体语言的组合来提供本体的能力。本体使用预定义的、保留的词汇来定义类以及它们之间针对特定感兴趣区域或更多的关系。由万维网联盟(W3C)定义的资源描述框架模式(RDFS)(例如，RDF词汇描述语言1.0：RDF模式)提供了用于资源描述框架(RDF)的特定词汇，其可以用于定义类和属性。Web本体语言(OWL)使用可用于为web构建更多表达本体的附加资源来扩展RDFS词汇。

RDF是用于在web中表示信息的框架。RDF本质上是数据模型。它的基本构建块是资源属性值三元组，称为语句。RDF已经被赋予XML、JSON等语法。

图2图示了可以使用RDF的语义示例。在该示例中，语句801图示了John Smith的头衔是教授，其可以以RDF语言802表示，如图2所示。xmlns:uni 803是自定义域名，其中属性(名称和头衔)被定义为RDFS的一部分。RDF是与域无关的，使得不对特定的使用领域做出假设。由用户在称为RDF模式(RDFS)的模式语言中定义自己的术语。RDFS定义了RDF数据模型中使用的词汇。在RDFS中，可以定义词汇，可以描述对象之间的关系，并且可以指定属性以应用于特定种类的对象，其可以包括对象可以采取的值。

Web本体语言(OWL)使用可用于为web构建更多表达本体的附加资源来扩展RDFS词汇。OWL引入了关于RDF文档的结构和内容的附加限制，以使得处理、推理在计算上更可行。例如，OWL定义对应于标准集合运算符的属性：交集(intersection)、并集(union)和补集(complement)，以定义类(class)的布尔组合。图3图示了使用交集来定义概念父(Father)的示例。父正是类父母(Parent)和男性(Male)的交集。换句话说，任何是父的人既是父母又是男性，任何父母又是男性的人都是父。乍一看，它可能看起来OWL等同于父是rdfs:subClassOf Parent和父是rdfs:subclassOf Male。然而，这两个subClassOf语句只声明所有父必须是父母和男性。其不能被用来仅根据其性别和父母身份而推断某人是父(如使用owl:intersectionOf可以做到的那样)。

OWL使用RDF和RDFS、XML模式数据类型和OWL命名空间。OWL词汇本身在命名空间http://www.w3.org/2002/07/owl#中定义，通常由前缀owl引用。数据类型表示使用URI识别的数据值的范围。OWL允许使用多个预定义的数据类型，其中大多数在XML模式定义(XSD)命名空间中定义。OWL允许用户通过扩展XSD来定义自己的数据类型。图4和图5都图示了在XSD中定义数据类型的示例。

来自不同命名空间的现有本体

存在许多已经开发和共享的本体。它们可以为扩展和重用提供基础。还有一些本体提供了狭义范围的感兴趣区域的深度表示。使用这种本体，它可以不必被扩展，而是简单地直接使用或广义使用。以下是与M2M***高度相关的这种本体的一些示例。

朋友的朋友(FOAF)项目维护FOAF本体，其表达与在万维网上共享关于朋友的信息相关的信息。本体包含用于捕获个人信息、电子邮件地址、在线帐户和即时消息信息以及在线文档和图像的类和属性。FOAF项目的目标是提供以独立于应用程序和与网站无关的方式捕获用户的在线生活的方法，以为了打破在web上分割各种社区的墙壁。为个人定义的公共属性示例(foaf:Person)包括foaf:name、foaf:title、foaf:homepage、foaf:interest和foaf:topic_interest等。

由W3C语义传感器网络孵化器组(SSN-XG)开发语义传感器网络(SSN)本体。SSN本体描述传感器和观察以及相关概念。SSN本体模型包含可用于表示传感器或其观察的特定方面的类和属性，例如传感器、观察、感兴趣的特征、感测的过程(例如，传感器如何操作和观察)、传感器如何被部署或附接到平台、传感器的测量能力以及它们的环境和在特定环境中的传感器的生存特性。类的示例可以包括ssn:Sensor、ssn:SensorInput和ssn:SensorOutput等。属性的示例可以包括ssn:hasMeasurementCapability、ssn:observationSamplingTime和ssn:qualityOfObservation等。参见http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/images/OntStructure-Overview.jpg，其全部内容通过引用并入本文。

IEEE 11073(ISO/IEEE 11073，Health informatics–Personal health devicecommunication standards(健康信息学-医疗/健康设备通信标准))个人健康数据(PHD)标准是一组解决个人健康设备(例如体重秤、血压计、血液葡萄糖监视器等)的互操作性的标准。

IEEE 11073-20601(IEEE 11073-20601，Health informatics–Personal healthdevice communication–Part 20601:Application profile–Optimized exchangeprotocol(健康信息学-个人健康设备通信-部分20601：应用简档-优化的交换协议))是定义通用数据类型、消息类型和通信模型的框架标准。其支持只需要为该特定类型的个人健康设备定义数据模型的任何数量的(相对小的)“设备专用化”标准(诸如用于体重秤的IEEE11073-10415标准)。

IEEE 11073-20601定义了诸如医疗设备***(MDS)和度量类的类。对于MDS，每个代理都有一个MDS对象，其识别它并报告其状态。MDS对象的属性将其识别给管理员，表示时间和状态，并提供其它信息。MDS然后包含由以下类表示的一些对象中的零个或多个。度量类是表示测量、状态和上下文数据的所有对象的基类，其还具有许多子类，例如数值可以表示单个测量。

图6图示了其中由IEEE 11073-10415定义体重秤的域信息模型的实际示例。图6示出了每个体重秤包含用于体重的所需的一个数值对象和用于体高和体重指数的两个可选数值对象。

图7图示了其中由IEEE 11073-10407定义血压监视器的域信息模型的另一个示例。这示出每个血压包含两个数值对象：一个针对收缩压、舒张压和平均动脉压(MAP)的强制性复合数值对象，以及一个针对脉搏率的可选数值对象。

oneM2M服务层

正在开发的oneM2M标准(oneM2M-TS-0001 oneM2M Functional Architecture-V-0.6.1(oneM2M-TS-0001 oneM2M功能性架构-V-0.6.1))定义了如图8所示的称为“公共服务实体(CSE)”的服务层。服务层提供可以由不同的“垂直”M2M仓(silo)***和应用(例如电子健康、车队管理和智能家庭)使用的“水平”服务。CSE支持四个参考点，Mca、Mcc、Mcc'和Mcn。Mca参考点与应用实体(AE)接口连接。Mcc参考点与同一服务提供商域内的另一CSE接口连接，并且Mcc’的参考点与不同服务提供商域中的另一CSE接口连接。Mcn参考点与底层网络服务实体(NSE)接口连接。NSE向CSE提供底层web服务，例如设备管理、位置服务和设备触发。CSE包含称为“公共服务功能(CSF)”的多个逻辑功能，例如“发现”、“数据管理和储存库”。图9图示了oneM2M的CSF。

oneM2M架构实现应用服务节点(ASN)、应用专用节点(ADN)、中间节点(MN)和基础设施节点(IN)。ASN是包含一个CSE并且包含至少一个AE的节点。物理映射的示例是驻留在M2M设备中的ASN。ADN是包含至少一个AE并且不包含CSE的节点。物理映射的示例是驻留在受限M2M设备中的ADN。MN是包含一个CSE并且包含零个或多个AE的节点。MN的物理映射的示例是驻留在M2M网关中的MN。IN是包含一个CSE并且包含零个或多个AE的节点。IN的物理映射的示例是驻留在M2M服务基础设施中的IN。

在(Service Component Architecture,TS-0007 Service ComponentArchitecture-V-0.2.0(服务组件架构，TS-0007服务组件架构-V-0.2.0))中描述的M2M服务架构通过指定提供给M2M应用和M2M服务提供商的M2M服务来增强oneM2M功能架构。如图10所示的组件是服务暴露组件、网络服务利用组件和远程服务暴露组件。服务暴露组件向AE暴露服务。网络服务利用组件消耗来自NSE的服务。并且远程服务暴露组件连接来自不同M2M环境的服务。

发明内容

如上所述，存在可由M2M***重用的若干现有的公共基础本体。如果M2M***重定义那些公共的基础本体(这也会降低M2M***与其它***之间的互操作性而不重用现有的基础本体)，这可能不是有效的。例如，在本文更详细讨论的使用情况下，为了描述健身房会员、部署在健身房中的设备的语义，M2M***可能需要具有相应的本体，诸如用于描述人的本体、用于描述传感器的本体或血压监视器。在不使用诸如FOAF本体、SSN本体、IEEE 11073个人健康数据模型的现有基础本题的情况下，M2M***可以重定义那些本体。如果重定义这些本体，这些本体可能不能与现有的本体互操作，则这防止M2M***和其它***彼此理解。

M2M***还可能需要合并来自不同垂直的本体，使得由一个垂直定义的本体可以通过M2M服务层由其它垂直共享和使用。现有的M2M***缺乏本体管理的支持。该议题包括以下议题。第一个议题，没有可以使用其它***建模M2M***的高级本体。需要这样的本体以从本体共享和重用的角度理解M2M***如何与其它***交互。第二个议题是，缺乏M2M***如何合并来自M2M***外部的不同命名空间的域特定本体以使得它们可以被M2M***存储、发现和重新使用的机制。第三个议题，缺乏M2M***可以如何合并来自M2M***内部不同垂直的本体的机制。第四个议题是，缺乏如何可以有效地存储向M2M***发布的本体以促进本体发现的机制。

本文公开了M2M本体处理器(MOP)，其负责处理、存储发现功能或向从M2M域的外部或内部发布的本体提供发现功能。MOP可以在功能上由本体处理组件(OPC)、本体分类组件(OCC)、本体发现组件(ODC)和本体储存库(OR)组成。OPC可以处理M2M命名空间外部和内部的已发布的本体，其可以用于向对象/实体提供语义信息。OCC可以对本体进行分类并将它们存储在本体储存库中的正确层级/位置中以用于发现和使用。ODC可以提供本体发现并确定请求者使用的匹配的一个或多个。OR可以存储在M2M域外部和内部发布或生成的任何本体模型。那些本体可以用于资源以实现语义。因此，OR可以与OCC和ODC两者交互。

MOP功能性还可适用于除M2M之外的其它命名空间/***。例如，W3C还可以采用MOP功能来处理、分类和存储从M2M命名空间发布的本体。

公开了M2M高级本体模型和MOP的oneM2M的示例，以及OR的资源树示例。本公开还讨论了本体资源内的类和关系的oneM2M示例，其促进了语义注释对多个本体的使用并且有助于推理。

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

附图说明

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

图1图示了患者监视应用；

图2图示了语义示例；

图3图示了owl:intersection的示例；

图4图示了定义XSD中的数据类型的示例；

图5图示了定义XSD中的数据类型的示例；

图6图示了由IEEE 11073-10415定义的体重秤的示例性域信息模型；

图7图示了由IEEE 11073-10407定义的血压监视器的示例性域信息模型；

图8图示了示例性oneM2M架构；

图9图示了示例性oneM2M公共服务功能。

图10图示了示例性oneM2M服务架构；

图11图示了健身房中的示例性M2M用例；

图12图示了可以实现本体管理的示例性***；

图13图示了示例性M2M本体处理器；

图14图示了本体处理单元的示例性方法；

图15图示了用于发布本体消息的示例性消息流；

图16图示了OWL中的示例性本体模板；

图17图示了用于将本体转换为兼容格式的OPC的示例性方法。

图18图示了概念映射咨询的示例性消息流；

图19图示了本体分类组件的功能性的示例性概要；

图20图示了本体储存库的示例性结构架构；

图21图示了存储在本体储存库中的资源的示例性层级；

图22图示了存储在针对非M2M命名空间的本体储存库中的示例性资源；

图23图示了存储在针对M2M命名空间的本体储存库中的示例性资源；

图24图示了本体发现组件的示例性功能架构；

图25图示了用于本体发现的示例性消息流；

图26图示了示例性oneM2M本体管理能力服务功能；

图27图示了oneM2M服务组件架构中的本体管理的示例性实施架构；

图28图示了本体储存库的示例性资源树结构；

图29图示了由oneM2M实施方式使用以将其本体发布到另一个外部命名空间的示例性消息交换；

图30图示了示例性高级本体模型；

图31图示了M2M高级本体的示例性oneM2M资源定向架构(ROA)；

图32图示了oneM2M命名空间中的示例性抽象；

图33图示了oneM2M命名空间中的示例性抽象；

图34图示了用于M2M语义支持的示例性功能架构；

图35图示了ETSI M2M架构；

图36图示了具有语义节点的M2M架构；

图37图示了M2M语义节点架构；

图38A是图示用于建立语义节点层级的方法的一个示例的流程图；

图38B更详细图示了图38A中的步骤；

图39图示了语义节点注册的消息流；

图40图示了由子代发起的父子关系更新；

图41图示了处理语义相关资源发现的流程图；

图42图示了RESTful语义节点操作的消息流；

图43图示了语义相关资源发现、检索和验证过程的消息流；

图44图示可以用由兄弟/父/子语义节点存储和管理的语义相关资源更新的语义节点的流程图；

图45图示了具有相同语义的资源分组的流程图；

图46图示了语义相关资源推送；

图47图示了设备从一个区域网络移动到另一个区域网络的情况；

图48图示了数据/语义相关资源移动的消息流；

图49图示了具有独立语义节点的ETSI M2M架构；

图50图示语义节点资源结构；

图51图示SS资源结构；

图52图示了具有集成语义节点的ETSI M2M架构；

图53图示了xSCL资源结构；

图54图示了<scl1>上的语义相关资源结构；

图55图示了contentInstance语义；

图56图示了资源和语义检索的消息流；

图57图示了具有独立语义节点的3GPP MTC架构；

图58图示了具有独立语义节点的3GPP MTC架构；

图59提供了如本文所述的语义节点的使用的一个示例的图示；

图60A是其中可以实现一个或多个公开的示例的示例机对机(M2M)或物联网(IoT)通信***的***图；

图60B是可以在图60A所示的M2M/IoT通信***内使用的示例架构的***图；

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

图60D是其中可以实现图60A的通信***的方面的示例计算***的框图；

图61是用于利用M2M本体管理和语义互操作性的示例性图形用户界面；

图62图示了示例性语义传感器网络本体；

图63图示了示例性oneM2M基本本体；

图64图示了示例性<ontology>资源结构；

图65图示了示例性<ontology>资源结构；

图66图示了<class>的示例性资源结构；

图67图示了<relationship>的示例性资源结构；

图68图示了到oneM2M基本本体的示例性<Ontology>资源映射；

图69图示了示例性<Ontology>资源结构；和

图70图示了可以通过由其它资源使用的方法来订阅的示例性<ontology>资源。

具体实施方式

机器对机器(M2M)***可以包括容纳语义相关资源的语义节点。M2M***的语义相关资源可以基于集合专有本体。但是存在许多可以由M2M***重用的现有的公共基础本体。依赖于专有本体可以影响M2M***与其它***的互操作性。对于M2M***使用已经存在的本体(诸如朋友的朋友(FOAF)或语义传感器网络(SSN)本体)可能更有效。在M2M***内，还可以存在不同的垂直，例如电子健康、车队管理或智能家庭。M2M***内的这些垂直也可以具有不同的本体。本文公开了本体处理器和用于解决本体的管理和互操作性的其它机制。本体处理器可以驻留在例如M2M***的一个或多个语义节点上。

以下呈现语义节点架构的简要概述以给出关于本体处理器(其可驻留于语义节点)的上下文。在对应于图35-图59的描述中提供关于语义节点架构的更多细节。这些是在ETSI的上下文中的示例，但可以在其它架构的上下文中考虑。

在常规的机器对机器(M2M)***中，M2M应用(托管在终端设备以及后端网络服务器上)需要预先同意交换的数据的公共定义。这主要是由于缺乏能够代表应用解析、解释或处理M2M数据的语义感知的M2M服务层。在当前M2M***中，M2M服务层缺乏语义感知能力，因此流经或存储在M2M服务层内的数据被视为不透明信息。

这种语义感知的缺乏防止M2M服务层提供允许M2M应用所产生的数据被M2M服务层有效地抽象或虚拟化以使得在即使其没有数据起源的应用的任何先验知识的情况下其可被不同应用发现、访问、解释和共享的服务。作为结果，被感测和作用的物理实体(例如，电器、人、汽车、建筑物的房间等)可能不能被M2M服务层有效地虚拟化/抽象化，并且物理实体被视为通用实体、环境固有的，并且不绑定到特定M2M应用。为了克服这种限制，在M2M***中传输的数据可以与语义信息相关联和集成，使得语义感知M2M服务层可以具有与M2M应用相同的数据知识。这样做，M2M服务层可以更好地促进跨应用的数据共享，并向M2M应用提供增值语义感知服务(例如，在不同应用之间的数据聚合、数据共享等)。

例如，在图1所示的患者监视应用中，可以存在托管在监视患者的生命体征(例如，血压、温度、氧气、心率等)的每个无线传感器设备上的单独的应用。同样，可以存在在网络中托管的可以利用该信息的单独的应用(例如，与患者的医生、私人教练、家庭成员、救护车护理人员等相关联的应用)。然而，没有来自每个无线传感器设备的M2M语义感知服务数据的情况下，网络应用可能难以发现、共享和理解来自设备应用的信息，除非网络应用具有在无线传感器设备上托管的应用的和它们产生的信息类型(例如，位置/地址、数据的单位、数据的上下文等)先验知识。

语义节点可以在M2M***中提供以下功能以支持M2M服务层语义感知和数据抽象：(i)对存储语义相关资源的支持和/或对存储语义相关资源的服务器的接口的支持；(ii)对用于创建、检索、更新和删除语义相关资源的机制的支持；和(iii)发布和发现语义相关资源的能力。

如本文所描述的，语义节点是可以托管在网络中的独立计算设备(例如，服务器)上或托管在网络内的现有实体上的逻辑实体，例如M2M网关、M2M设备、M2M服务器等。语义节点可以被视为存储语义相关资源建模的储存库。例如，用于血压的传感器设备可能想要理解如何描述其数据，因此其查询附近的语义节点以找出是否存在已经定义的血压类。如果是，则语义节点用其在本地发现的血压类来响应传感器设备。如果否，则语义节点可以查询其它语义节点(例如，兄弟或父)。语义节点的使用可以减少使终端设备存储数据模型的需要。

语义节点存储和管理语义相关资源。语义相关资源通常描述其它资源，例如，存储在资源树<SCL>、<application>、<container>、<contentInstance>下的ETSI M2M资源，其需要具有与其相关联的语义相关资源以能够理解其语义。在一个示例中，语义相关资源可以具有三种类型中的一种：类、关系和词项。这种分类提供与语义Web的当前技术的兼容性，并且使得M2M***能够利用现有的语义相关资源。本文中存在基于ETSI和oneM2M的示例的混合。本领域技术人员将能够理解ETSI和oneM2M具有相似的资源树结构，并且应该能够在任一个中中继这里的概念。

如本文所讨论的，语义节点可以在不同级别的M2M***中部署，例如M2M区域网络、M2M接入网络和M2M核心网络，使得不同的层级形成层级。相同级别中的语义节点可以是分布式的并且具有兄弟关系。关于建立和维持语义节点的这种混合架构的机制被公开，其提供了对不同级别的抽象和与现有网络层级的兼容性的好处。

图11-图34及其伴随的描述提供了结合与下面描述的用于本体管理的方法、设备和***相关的语义节点架构和平台的示例的进一步信息和理解。本文公开了M2M本体处理器(MOP)，其负责处理、存储发现功能或向来自M2M域的外部或内部发布的本体提供发现功能。

应当理解，执行本文所示的步骤(例如，图12-图34等)的实体是可以以存储在如图60C或图60D中所示的设备、服务器或计算机***的存储器中的软件(例如，计算机可执行指令)并且在其处理器上执行的形式实现的逻辑实体。也就是说，图12-图34中所示的方法等可以以存储在计算设备(诸如图60C或图60D中所示的设备或计算机***)的存储器中的软件(例如，计算机可执行指令)的形式来实现，该计算机可执行指令在由计算设备的处理器执行时执行图12-图34中所示的步骤。在示例中，通过下面关于M2M设备的交互的进一步细节，图25的请求者771可以驻留在图60A的M2M终端设备18上，而图13的MOP 721或服务器729可以驻留在图60A的M2M网关设备14上。

对于另外的角度，图11图示关于本体管理的健身房用例。如图11所示，健身房可以具有为其顾客部署的多个不同的设备，诸如用于感测周围温度/湿度的环境传感器706、跑步机703、体重秤702和血压监视器701。可以在资源数据库中存储与设备(例如，应用资源)相关的资源和由设备生成和报告的数据资源。

为了向图11的设备提供语义和其测量数据、以及健身房会员，需要各种本体。每个本体可以用于描述每个不同类型的设备的语义信息以及测量的数据。MOP可以驻留在网关704中。存在可以被发布到MOP的外部本体，其可以被利用并且用于描述健身房中的实体的语义。例如，可以通过发布消息将FOAF、SSN和IEEE 11073-10415发布到M2M命名空间，如关于表3至表6更详细地讨论的。结果，MOP可以处理、存储、发现、以及以其它方式有助于使用外部本体。

继续参考图11，MOP可以以可由M2M***采用的统一语言存储发布的本体。该语言可以是来自语义Web的RDFS/OWL。为了该示例的简化说明，我们假设M2M***在描述已发表的本体时使用RDFS/OWL。M2M***还可以采用其它语言或开发其自己的语言。所提出的M2M高层本体模型以及MOP的功能是独立的，并且不依赖于M2M***使用的特定本体语言。在大多数情况下，M2M***将知识表示为概念(本体)的层级，其可以在M2M域的外部或M2M域的内部，并且使用共享词汇表示这些概念的类、属性和相互关系。这将在下面更详细地讨论。

图12图示了可以实现本体管理的示例性***720。在***720中可以存在多个命名空间，诸如M2M命名空间735和非M2M命名空间738。非M2M命名空间738包括可以位于服务器729上的一个或多个本体。如图12所示，M2M命名空间735(例如，oneM2M命名空间)包括可以是语义节点的多个M2M节点，诸如节点737、节点728和节点736。节点728和节点737可以与节点736通信地连接，节点736包括MOP 721。节点728可以包括包括电子健康的M2M垂直。节点737可以包括包括智能家庭的M2M垂直。节点737和节点728也可以具有多个其它M2M垂直。节点736还可以与位于非M2M命名空间738中的服务器729通信地连接。

图13图示了MOP 721的示例。MOP 721可以在功能上包括本体处理组件(OPC)726、本体分类组件(OCC)724、本体发现组件(ODC)723和本体储存库(OR)727。OPC 726可以处理M2M命名空间外部和内部的已发布的本体，M2M命名空间可以用于向对象/实体提供语义信息。处理的本体被输入到OCC 724以被正确地存储在正确的层级中以用于发现和使用。OCC724可以对本体进行分类并将它们存储在OR中的正确的层级/位置中以用于发现和使用。ODC 723可以提供本体发现并确定匹配的本体以供请求者使用。OR 727可以存储在M2M域外部和内部发布或生成的任何本体模型。那些本体可以用于资源以实现语义。因此，OR 727可以与OCC 724和ODC 723两者交互。OR可以被认为是逻辑实体语义节点的一部分。MOP 721功能还可以适用于除M2M之外的其它命名空间/***。例如，W3C还可以采用MOP功能来处理、分类和存储从M2M命名空间发布的本体。

图14图示了关于MOP 721的OPC 726的示例性方法730。在步骤731处，OPC接收本体。当发布时，所接收的本体消息(即，本体发布消息)可以具有特定格式，这将在下面更详细地讨论。本体可以来自外部命名空间(非M2M命名空间738)或内部命名空间(例如，M2M命名空间735)。在步骤732处，OPC 726确定所接收的本体的兼容性。OPC 726识别本体表示是否具有与在M2M命名空间中使用的格式相同的格式。例如，如果M2M命名空间内的所有本体由OWL表示，那么以其它格式表示的本体被认为在M2M命名空间内不兼容。在步骤733处，OPC726将非兼容本体转换为兼容格式。

本体发布消息可以包括如表1中总结的一个或多个字段，诸如命名空间、名称、兼容性、访问权限、主题、相关性或本体表示。表1的字段可以用于与外部命名空间(例如，非M2M命名空间738)相关联或与使其本体发布到OPC 726的M2M垂直(例如，节点728和节点737上的M2M垂直电子健康和智能家庭)相关联的消息。发布的本体可以是先前发布到OPC 726的本体的更新。

参考表1，命名空间字段指示所发布的本体的命名空间。名称字段指示所发布的本体的名称。兼容性字段指示包含在本体发布消息主体中的本体表示是否与由具有M2M命名空间(例如，M2M命名空间735)的M2M***735选择的本体表示兼容。为了简化本文关于本体管理所讨论的示例，将假设M2M***721由M2M命名空间735等效地包含，如图12所示。M2M***739可能支持多于一个的兼容格式。如果发出者(服务器729)没有事先预先检查其本体表示与MOP 721的兼容性，则该字段可以留空。否则，如本文更详细讨论的，服务器729可以用适当的内容填充该字段。

表1：本体发布消息字段说明

继续参考表1，访问权限指示本体可以如何被其它方和实体访问。访问权限对于与本体发布者具有不同关系的不同方(例如，个人、企业、政府或其它方)可以是不同的。访问权限字段可以看起来像表2。子字段操作了允许的操作，诸如RO(只读)、RW(读和写)等。子字段方显示允许对公开的本体进行操作的相应方，其可以是公开的(例如，每一方都可以对其进行操作)、与发布者具有某种关系方、单独方等。表2图示了几个示例，每个公共方能够具有对所发布的本体的读取访问，而仅具有与发布者相同的所有者(发布者可以是另一应用)的应用可以具有对所发布的本体的读和写访问。

表2：所发布的本体的访问权限

进一步参考表1，主题指定本体相关的主题。主题字段可以包含一个或多个关键字以描述本体。例如，当FOAF本体被发布时，提交的主题可以是“人”。该主题可以来自所有命名空间理解的公知/常用词汇，并且也可以被标准化。该字段也可以留空，因此OCC 724可以为所发布的本体决定相关主题，这在下面更详细地讨论。如表1所示，相关性指示所发布的本体是否与其它本体有任何相关性。例如，可以从存储在OR 727中的现有本体扩展或修改已发布的本体。例如，可以扩展FoAF本体以包括除已经定义的那些之外的人的更多属性。如表1所示，本体表示包含所发布的本体的表示。在一些情况下，发布者可以仅发布本体的URI。如果本体表示是非M2M兼容格式，则可以包括本体的模式。

如上面简要讨论的，本体可以来自外部命名空间(非M2M命名空间)或内部命名空间(例如，oneM2M命名空间)。参考图13，结合图14的步骤731，OPC 726可以从可以托管一个或多个非M2M命名空间的一个或多个服务器(例如服务器729)接收本体。服务器729可以向MOP 721主动地发布非M2M命名空间738的本体。MOP 721还可以请求来自MOP 721的更新的非M2M命名空间本体。来自MOP 721的请求可以基于事件，诸如时间、用户动作(例如，用户输入的命令)等等。服务器729或其上的命名空间可以由一个或多个管理机构(例如FOAF、SSN、IEEE、大学、企业、私人个人、政府或其它实体)主持。

继续参考图13和图12，结合图14的步骤731，OPC 726还可以从具有与MOP 721的M2M命名空间735相关联的一个或多个垂直的一个或多个M2M节点(诸如节点728和节点737)接收本体。垂直的示例包括电子健康(节点728)、车队管理和智能家庭(节点737)。节点728和节点737可以主动地向MOP 721发布本体。MOP 721还可以从节点728和节点737请求更新的M2M垂直本体。请求可以基于事件，诸如时间、用户动作(例如，用户输入命令)等等。节点728、节点737或节点728和节点737的托管垂直可以由诸如FOAF、SSN、IEEE、大学、企业、私人个人、政府或其它实体的一个或多个管理机构主持。

图15图示了用于发布本体消息的示例性消息流。图15的消息流可以适用于外部命名空间(例如，非M2M命名空间738)或内部命名空间(例如，M2M命名空间735)。为了简单起见，如图15所示，发布者741表示外部或内部命名空间。在步骤742处，发布者741可以查询M2M***739采用的本体表示格式。先决条件可以是发布者理解M2M***(例如，RDFS/OWL)使用的表示其在M2M***739的本体储存库中的原始本体的模式。例如，在oneM2M(本文更详细地讨论)中，查询可以旨在检索图28中的<OR>资源的格式属性。替选地，对于步骤742，可选地，发布者741可以选择检查其想要用MOP 721发布的本体的表示的兼容性。该消息可以是来自本体发布消息的单独消息。发布者741可以输入其在消息中表示本体所使用的格式。MOP可以确定所接收的格式是否是它正采用的格式。并且相应的响应消息(是或否)被返回给发布者741。M2M***739使用的格式可以附加在响应消息中，以使发布者知道这一点。

继续参考图15，在步骤743处，基于在步骤742请求从发布者发送的请求信息，根据在步骤742处的发布者，MOP可以返回M2M***739采用的兼容性结果或格式(其可以是本体模板)。本体模板可以是如图16所示的本体，这是比较简单的。在步骤744处，发布者741可以基于来自MOP 721的反馈选择将要发布的本体转换为兼容格式。先决条件可以是发布者741理解RDFS/OWL模式以表示其在RDFS/OWL中的原始本体。MOP 721可以处理本体并将本体转换为M2M***739采用的格式。可选地，发布者741还可以直接以其自己的格式发布原始本体。MOP 721的转换可以基于如表8所示的概念名称映射表，如本文更详细地讨论。图15了发布者741将本体转换为兼容格式的场景。

进一步参考图15，在步骤744处，发布者741创建发布消息，其可以包含表1的字段。为了说明的目的，表3到表7图示了可以包含在不同本体的字段中的内容。

表3：FOAF本体的发布消息

表4：SSN本体的发布消息

表5：IEEE 11073-10415本体的发布消息

表6：IEEE 11073-10407本体的发布消息

表7：从具有M2M命名空间的M2M垂直发布BP的消息

表3示出了可以是来自具有FOAF本体的FOAF_Project命名空间的发布消息。命名空间字段设置为“FOAF_Project:http://xmlns.com/foaf/0.1/”。名称字段设置为FOAF。FOAF本体也写在RDF/OWL中，因此兼容性字段设置为Y。访问权限设置为公开(FOAF对公众开放)。主题字段被设置为“人”。本体表示的URL被包含在消息主体中，MOP 721能够从该消息主体下载并获得本体。

表4示出了来自具有SSN本体的SSN_Project命名空间的发布消息。命名空间字段设定为“SSN_Project:http://purl.oclc.org/NET/ssnx/ssn”。名称字段设定为为SSN。SSN本体也写在RDF/OWL中，因此兼容性字段设定为Y。访问权限设定为公开(SSN对公众开放)。主题字段设定为“传感器”。本体表示的URL包含在消息主体中，MOP 721能够从该消息主体中下载并获得本体。

表5示出了来自体重秤的数据本体的IEEE 11073命名空间的发布消息。命名空间字段设定为IEEE 11073。名称设定为“scale:IEEE 11073-10415”。发布者以不同于RDF/OWL的模式发布本体。因此，兼容性字段设定为N。OPC 726需要注意将本体转换为兼容格式。下面关于表9更详细地讨论所得到的本体。访问权限被设定为IEEE成员(仅IEEE成员能够访问IEEE 11073-10415的规范)。稍后，如果请求者想要访问此本体，则MOP 721需要与IEEE端点或应用进行检查以验证请求者的成员身份。主题字段设定为“健康”。本体表示包含在消息主体中，其包含本体的模式，后面是每个字段的值。

表6了来自血压监视器的数据本体的IEEE 11073命名空间的发布消息。命名空间字段被设定为IEEE 11073。该名称被设定为“BPMonitor：:IEEE 11073-10407”。发布者以M2M***739采用的兼容格式发布本体。因此，兼容性字段设定为Y。访问权限设定为IEEE成员(只有IEEE成员才能访问IEEE 11073-10407的规范)。主题字段设定为“健康”。本体表示包含在消息主体中，它遵循XSD中用于描述简单和复杂数据类型的模式。

表7示出了来自血压(BP)本体的M2M垂直(例如，电子健康)的发布消息。命名空间字段设定为M2M。兼容性字段被设定为Y，因为垂直遵循表示本体的M2M兼容格式。主题字段留空。本体表示包含在消息主体中，它遵循XSD中用于描述简单和复杂数据类型的模式。

进一步参考图15，在步骤746处，MOP 721的OPC 726处理所发布的本体，并且OCC724可以在OR 727中在正确的层级存储本体，这将在下面更详细地讨论。在步骤747处，在步骤746处成功处理和存储发布的本体之后，MOP 721可以将存储的本体的URI返回到发布者741。

如上面简要讨论的，对于以与M2M域不兼容的格式表示的本体(例如，表5)，OPC726可以将该本体转换为兼容格式。例如，如果M2M命名空间内的所有本体由OWL表示，那么以其它格式表示的本体被认为在M2M命名空间内不兼容。图17图示了OPC 726将本体转换为兼容格式的示例性方法。在步骤751处，OPC 726读取本体发布消息的消息主体，其包含本体的模式，随后是每个字段的值。在步骤752处，OPC 726基于该模式，OPC能够解析每个字段。本体是预定义的、保留的词项的词汇表，用于定义类以及可以用于特定的感兴趣区域的类之间的关系。来自M2M命名空间735的外部或内部的每个本体通常由两个概念组成：类和关系。OPC 726维护可由M2M命名空间735与其它命名空间使用的概念名称之间的可能映射。在RDF/OWL中，对应的概念名称是类和属性，以及xsd：complextype/xsd：simpletype和xsd：element。在步骤752处，OPC 726创建概念映射建议。表8示出了概念名称之间的示例性映射。可以由MOP 721增量地和动态地维护该映射表，这意味着可以由MOP 721学习和添加新的映射。当MOP 721遇到其不能找到对应映射的新概念名称，因此不能理解发布的本体时，它可以提出可能的映射并咨询发布者。发布商可以确认映射或建议新映射。图18图示概念映射咨询的消息流。

表8：概念名称映射

M2M命名空间	其它命名空间
		<u>xsd:complexType</u>	<u>dataModel</u>
xsd:element	元素
		属性	关系、特性

参考图18，在步骤755处，MOP 721将概念映射建议发送到本体发布者741，本体发布者741包含所提出的映射以及来自M2M命名空间735的概念名称的含义。注意，M2M命名空间也可以被称为M2M域。在步骤756处，发布者741将接收的概念名称的含义与其自己的名称进行比较，并且决定概念映射匹配。在步骤757处，发布者741向MOP 721发送同意概念映射建议的确认响应。在步骤758处，MOP 721将该映射本地存储在概念名称映射表中，例如类似于表8。表8示出了将新概念名称映射(下划线)添加到表。基于映射，OPC能够将已发布的本体转换为兼容格式。例如，表5以不同的格式显示了发布的本体。OPC将dataModel映射到xsd：complexType，元素映射到xsd：element。结果，所发布的本体可以被转换为如表9所示的表示。

表9：11073-10415的转换的本体表示

图19图示了本体分类组件的功能的概要。OCC 724接受作为OPC 726的输出的M2M兼容本体。

OCC 724对本体进行分类并定位正确的层级以存储它。分类包括决定本体是否属于非M2M命名空间(例如非M2M命名空间738)或M2M命名空间(例如，M2M命名空间735)，其属于哪个命名空间，其属于哪个主题等。OCC 724解释发布的本体并提取本体的基础。基本原则包括本体中包含的类和属性。每个类和属性可以并入M2M***中，M2M***将存储在本体储存库(OR)727中。

OR 727将本体存储在可以简化发现的结构中。在图20中示出了示例性结构架构。OR 727区分从M2M命名空间735的外部和内部发布的本体，因此其在逻辑上由两部分组成：非M2M命名空间和M2M命名空间。用于非M2M命名空间的OR 727在架构上具有三个级别：第一级是单独的命名空间，其可以是如上述示例中的FOAF_Project、SSN_Project、IEEE 11073。第二级可以包含每个单独命名空间下的本体。第三级可以包含每个单独本体的基础，其包括本体中定义的类、关系和词项。

继续参考图20，用于M2M命名空间的OR 727可以在架构上具有三个级别。第一级是单独主题，其是发布的本体可能与其相关的可能的关键字，例如，人(其包含与描述人相关的本体)、电器(其包含与描述任何种类的电器相关的本体)。第二级可以包含与每个单独主题相关的本体或虚拟本体。虚拟本体是与从非M2M命名空间发布的主题相关的本体。实际本体表示不存储在虚拟本体下，而是具有到存储在OR 727中用于非M2M本体层级的实际本体的链接。第三级可以包含每个单独本体的基础，其包括本体中定义的类、关系和词项。存储在OR 727中的资源的详细层级在图21中示出。

以下讨论使用关于表3-表7描述的公开的本体的一个或多个示例来讨论存储在OR727中的OCC 724的处理以及OR 727的每个级别中的相应内容。图22图示了用于非M2M命名空间738存储在OR 727中的示例性资源。对于在表3所示的消息中发布的本体，OPC 726从包含在消息主体中的链接下载rdf/xml文件中的本体。OCC 724将该本体存储在名为FOAF_Project的新命名空间下。OCC 724还提取在本体中定义的类和属性，并将它们相应地存储在类和关系子级下。同时，OCC 724创建新的主题(人)，并将实际本体的链接存储为该主题下的虚拟本体之一。

继续参考图22，对于在表4所示的消息中发布的本体，OPC 726从包含在消息主体中的链接下载OWL文件中的本体。OCC 724将该本体存储在名为SSN_Project的命名空间下。OCC 724还提取在本体中定义的类和属性，并将它们相应地存储在类和关系子级下。同时，OCC 724创建新的主题(传感器)，并且将实际本体的链接存储为该主题下的虚拟本体之一。

继续参考图22，对于在表5和表9中所示的消息中发布的本体，OCC 724将本体存储在名为IEEE 11073的新命名空间下。OCC 724还提取本体中定义的类并将它们存储在类子级下。同时，OCC 724创建新的主题(健康)，并且将实际本体的链接存储为该主题下的虚拟本体。注意，因为空间考虑所以与图21不同地绘制图23。

参考图23，对于在表7所示的消息中发布的本体，OCC 724存储在M2M命名空间下的本体。由于发布消息中的主题字段为空白，所以OCC 724可以决定该本体的相关主题(其是现有的主题——健康)。注意，本体可以与多于一个主题相关，本体表示可以被存储一次，并且其链接可以存储在其它不同主题中的对应虚拟本体下。在椭圆763、椭圆764、椭圆765和椭圆766中引用的本体是真实本体，其包含原始本体的URI。椭圆767是真实的本体。

图24图示了ODC的示例性功能架构。本体发现组件(ODC)723接受来自诸如M2M应用(例如，oneM2M中的AE)的任何实体的发现请求，分析发现请求，并从OR 727为M2M命名空间735找到匹配主题，并搜索匹配主题——将请求的匹配本体或基础返回给请求者。这里的ODC讨论类似于关于语义相关资源的发现、检索和验证过程所讨论的，但是具有调整的资源层级。

发现请求消息中的示例性字段和描述可以包括请求类型、搜索关键字或响应类型。表10显示字段的摘要。请求类型指示请求者正在寻找什么，其可以是整个本体或本体内的基础。因此，该字段的可能值可以是以下：本体、类、关系。搜索关键包括由请求者发送的搜索关键。注意，本体还可以具有它们自己的语义(例如，它们所属的命名空间或主题)(其由图34中的语义储存库维护)，作为结果，可以通过图34中的语义查询处理器来执行本体发现。响应类型指示请求者期望的响应，其可以是匹配结果的URI或匹配结果的URI和表示。

表10：发现请求消息字段和说明

图25图示了本体发现的示例性消息流。在步骤772处，请求者771(例如，M2M应用，例如，另一健身房中的另一血压监视器应用)向MOP 721发送发现请求。请求类型被设定为类，并且搜索关键被设定为“健康”和“血压“和”BP“，其指示请求者对发现建模血压的类感兴趣。响应类型设定为URI，这意味着请求者只需要匹配类的URI。请求者可以使用所发现的本体来描述其自身或其测量数据等的语义信息。

在步骤773处，MOP 721的ODC 723分析该请求，并在主题级搜索OR 727查找M2M命名空间735。ODC 723发现可能的匹配主题是健康。ODC 723进一步搜索健康主题下的本体，并找到两个匹配的本体。一个是虚拟的，其包含原始本体的URI：Non-M2M-Namespace(非M2M命名空间)/IEEE11073/11407/。另一具有URI：M2M-Namespace(M2M命名空间)/health/bloodPressure/。ODC 723最终找到两个本体下的两个匹配类，并且在步骤774处，将它们的URI返回给请求者771。在步骤775处，请求者771可以检索两个本体的表示，并且查看它们中的任何是否合适用于描述其数据。请求者771还可以扩展现有的任何一个以适合其自己的数据。例如，表6示出了IEEE 11073-10407发布的本体，其具有4个元素。表7示出了由M2M垂直发布的本体，其具有2个元素。客户端可以具有仅具有两个需要被描述的元素的数据。因此，表7中的本体将是合适的本体。

参考与图11相关联的健身房用例，可以有部署的不同的设备，例如用于感测周围温度/湿度等的环境传感器、用于健身房用户跟踪其体征的体重秤和血压监视器。与设备相关的资源(例如应用资源)以及由设备生成和报告的数据资源可以存储在资源数据库中。

为了向这些设备及其测量数据提供语义，每个设备可能需要发现满足其自身需求的本体并使用它。另一方面，健身房的会员也需要本体来描述其简档以及与彼此的关系。以下示出了如何可以在健身房用例中发现和使用由OR 727维护的公开的本体，使得它们不需要再次由M2M命名空间重新创建。

健身房会员707的电话(以下为健身房会员)可以向MOP 721发送发现请求(在消息中包含类、人、URI)以找到本体来描述他/她的简档和与他人的关系，MOP可以将个人主题下的FOAF本体匹配到该请求，并且将本体的URI返回到健身房会员707。为了使用它，健身房会员707通过瞄准URI来从OR 727检索本体表示。

环境传感器706的应用可以向MOP 721发送发现请求(在消息中包含类、传感器、URI)以找到本体以描述其测量数据，MOP 721可以匹配传感器主题下的SSN本体，并将本体的URI返回给传感器。为了使用它，环境传感器706通过瞄准URI来从OR 727检索本体表示。注意，由于环境传感器706是资源受限设备，它可能不具有处理SSN本体的整个表示的能力。环境传感器706可以进一步从URI发现本体的基础，并且仅检索它需要的基础(例如，ssn:SensorOutput)。

血压监视器701的应用可以向MOP 721发送发现请求(包含消息中的类、健康；血压、URI)以找到本体以描述其测量数据，MOP 721可以将该健康主题下的两个本体表示匹配岛该请求，并将本体的URI返回到血压监视器701的应用。为了使用它们之一，血压监视器701的应用通过瞄准URI从OR 727检索本体表示。

体重秤702的应用可以向MOP 721发送发现请求(包含类、健康；秤，该消息中的URI)以找到本体来描述其测量数据，MOP 721可以将健康主题下的本体匹配到该请求，并将本体的URI返回到体重秤702的应用。为了使用它，体重秤702的应用通过瞄准URI来从OR727检索本体表示。可能的是，从OR 727发现和检索的本体可能不满足设备(诸如环境传感器706、健身房会员707、血压监视器701的应用和体重秤702的应用)中的一个。可以根据其要求扩展或修改本体。

下面是可适用于oneM2M的特定示例的讨论。oneM2M定义了oneM2M服务层支持的能力。oneM2M服务层被实例化为包括公共服务功能集合(CSF)的公共服务实体(CSE)。在一个示例中，如图26所示，可以在CSE中作为oneM2M的CSF来托管MOP 721。作为另一个示例，MOP721可以是所讨论的语义节点的一部分(其也可以是oneM2M CSF)。

任何oneM2M垂直(即AE)可以经由Mca参考点与本体管理CSF通话以公布其本体或发现现有本体，或者其它CSE可以经由Mcc/Mcc’参考点与本体管理CSF通话以发布其本体或发现现有本体。来自oneM2M命名空间外部的发布者可以通过Mcc’参考点与本体管理CSF通话以发布它们的本体。因此，本文关于MOP所讨论的相应消息和提出的过程将适用于Mca、Mcc和Mcc’参考点。

图27还示出了在oneM2M服务组件架构(Service Component Architecture,TS-0007 Service Component Architecture-V-0.2.0(服务组件架构，TS-0007服务组件架构-V-0.2.0))中本体管理的示例性实施架构。oneM2M垂直(即AE)可以经由Mca参考点与本体管理服务组件通话以发布其本体或发现现有本体。来自oneM2M命名空间外部的发布者可以通过新的参考点Mcc/Mcc’与本体管理服务组件通话以发布它们的本体。上述部分中提出的消息和程序适用于这些参考点。

图28中示出了本体储存库(OR)的示例性的基于oneM2M的资源树结构，其具有两个子资源：<Non-M2M-Namespace>和<M2M-Namespace>。<OR>的格式属性指示oneM2M架构采用的本体表示格式。<Non-M2M-Namespace>存储从oneM2M之外的命名空间发布的所有本体。<M2M-Namespace>存储从oneM2M垂直发布的所有本体。表11示出了<namespace>属性及其描述。表12示出了属性<external-ontology>及其描述。表13示出了属性<内部本体>及其描述。<virtual-ontology>的actualLink(实际链接)属性示出了存储在<Non-M2M-Namespace>下的原始本体的链接。

表11<namespace>资源的属性

表12<external-ontology>资源的属性

表13<internal-ontology>资源的属性

另外，图28图示了所提出的<ontology>资源的子资源，其被实例化为<internal-ontology>和<external-ontology>。该资源在图70中示例并且包含子资源<class>、<relationship>和<term>。图70还指示可以通过另一资源所使用的方法来订阅到<ontology>资源。

图62图示了语义传感器网络(SSN)本体的示例性本体表示。如下表所提供的，可以关于语义本体提供示例。图63图示了oneM2M基本本体。如本文更详细地讨论的，可以存在到oneM2M基本本体的资源映射。简要地讨论oneM2M基本本体以用于帮助在下面的讨论中进行讨论。oneM2M基本本体正在开发中，作为用于提供语义功能所需的M2M服务层的更大规格体的一部分。该本体目前被设计为所需的最小本体(例如，规定最少数量的约定)，使得其它本体(例如这里描述的并且参考图62的语义传感器网络本体)也可以映射到oneM2M平台并且由oneM2M平台利用。在oneM2M中，外部本体可以用于描述应该在oneM2M实施方式中表示的特定类型的设备或真实世界“事物”(例如建筑物、房间、汽车、城市等)。目标是最大限度地重用现有工作以及提供语义驱动的互通解决方案。

下面参照图64至图68讨论的是<class>和<relationship>子资源的不同考虑。下面提供了对<class>和<relationship>资源的第一考虑。图64、图65、图69是图示构造属性的不同方式的<ontology>资源。图64和图65具有不同的结构化它们的描述属性的方式以在本体定义中维护类和关系信息。血压测量用作示例。图64和图65不同之处在于图65定义RDF三元组中的类和关系，这是语义信息的原始表达。图64进一步将三元组分成关系和对象。这两种方式可能影响语义发现和推理，以及创建本体资源的方式。

图66和图67中了用于对<class>和<relationship>资源的资源结构的第二考虑。表14和表15示出了这两个资源及其描述的属性。在该第二示例中，两个资源(<class>901和<relationship>905)具有描述本体内的关系以及诸如关系类906或限制907的其它特征的多个属性(诸如关系类906或限制907)。诸如“isSubjectOf”的属性(对于<class>901)具有可以采用不同的选项加以详述，其中一个选项中，属性包含单个值(<relationship>资源的URI)，另一个选项中属性包含元组(到<relationship>资源和对应的对象<class>资源两者的URI)。在另一变型中，这些值可以是字面值而不是相应资源的URI。

表14：<class>资源的属性

表15：<关系>资源的属性

<class>和<relationship>资源的第二实施例(图66-图67、表14、表15)及其变体(一些属性被提供为单个值或元组，或者被直接提供或者作为URI)可以对高级功能特别有用。理解关系类型可用于高级推理。例如，能够理解表示在本体中可用的泛化与专用化关系的所有关系、或者几个本体之间的等效类，可以用于高级推理。类似地，理解具有特定类作为主体的关系是什么，可以允许将派生或扩展的逻辑应用于基于特定类的查询。除了表14和表15中提供的使用来自SSN本体的概念的属性示例之外，图68图示了在本文中引入的(例如，关于图63)<Ontology>资源映射到oneM2M基本本体的示例。当考虑如图68所示的示例时，可以假定属性包含单个URI值。诸如<serviceClass>和<hasOperationRel>等的记法用于表达这些表示<class>类型的<service>资源以及<relationship>类型的<hasOperation>资源。记法isSubjectOf(hasOperation)表示具有值hasOperation的isSubject类型的属性。不是所有的属性都被示出，仅示出示例性的属性。

M2M***(例如，oneM2M)还可以向也可以采用MOP功能来处理、分类和存储本体的其它命名空间/***(例如，W3C)发布M2M本体。图29所示的消息流程是由oneM2M实施方式将其本体发布到另一个外部命名空间所使用的消息交换的示例。外部命名空间或***可以包括MOP或可以仅实现基本功能以支持这些消息并存储M2M本体或其链接，而不具有如上所述的MOP的一些分类和发现特征(诸如与图13至图19相关联的描述)。所使用的消息类似于上述消息(诸如与图13至图19相关联的描述)。除了消息交换之外，oneM2M MOP将执行步骤3，如果需要，将M2M本体转换成另一种格式。MOP功能可以适用于除M2M之外的其它命名空间/***。例如，W3C还可以采用MOP功能来处理、分类和存储从M2M命名空间发布的本体。

M2M高级本体模型

图30图示了高级本体模型。认为物理世界中的物体可以是物理对象。每个物理对象可以被建模为不同命名空间中的抽象对象。例如，可以通过具有FOAF命名空间的FOAF本体来建模人/健身房会员，可以通过具有W3C SSN命名空间的SSN本体来建模传感器，可以通过IEEE 11073命名空间来建模健康设备(体重秤、血压监视器)。同时，M2M***中的M2M节点(例如，M2M设备、M2M网关、M2M服务器)被抽象到M2M命名空间中的抽象对象，其一个示例是oneM2M。抽象对象包含功能实体，其可以由M2M***维护的资源表示。例如，如图31部分所示，物理对象被抽象到oneM2M命名空间中的M2M节点，其中每个可以包含AE或/和CSE。

图31图示了图30中所示的M2M高级本体论模型的示例性oneM2M资源定向架构(ROA)。M2M节点是物理对象的一个子类，其具有设备(Device)、网关(Gateway)和服务器(Server)的子类。M2M节点可以被抽象为oneM2M命名空间中的oneM2M节点。在oneM2M命名空间中，定义了四种类型的节点：AND、ASN、MN和IN，它们是oneM2M节点的子类。ADN仅包含AE。ASN包含一个CSE和一个或多个AE。MN包含一个CSE和零个或多个AE。IN包含一个CSE和零个或多个AE。这些可以通过如图31所示的“包含”关系来图示。图32和图33是可以在oneM2M命名空间中确定的抽象的不同示例。图32图示了其中物理对象是血压监视器的示例。血压监视器被抽象为包含AE的ADN。AE由资源树中的<bloodPressureAE>资源表示。图33图示了可以属于健身房用户的电话的示例。电话被抽象为包含CSE和AE的ASN。CSE由<phoneCSE>资源表示，AE可以是安装在电话上的健身房AE，其由资源树中的<gymAE>资源表示。物理对象只能在被抽象之后被本体建模。MOP 721负责处理这些本体。

M2M语义支持的功能架构

下面是关于本体的进一步讨论以给出进一步的观点。物理世界中的所有东西都可以被认为是物理对象。每个物理对象可以被建模为不同命名空间中的抽象对象。图30图示了物理对象和不同命名空间的抽象的示例性概述。可以存在任何数量的命名空间，例如源自物理对象711的抽象的命名空间712、命名空间713和命名空间714。每个命名空间可以具有一个本体或多个本体，其对一个或多个物理对象进行建模。

图34图示了用于M2M语义支持的示例性功能架构，这些组件可以是以下中的一个或多个：

·资源数据库存储从物理M2M设备收集的资源以及与M2M应用相关的任何资源，诸如M2M应用(常规资源)中涉及的人、设备等。M2M语义支持实现原始资源的语义以用于对它们的普遍理解/解释，以及对它们的任何高级处理，例如语义查询、数据分析等。

·本体处理器负责处理、分类、存储和提供M2M域外部和内部的发布的/生成的本体的发现功能。它包含存储本体的本体储存库。这些本体可以用于常规资源以实现语义。本体储存库可以被认为是这里介绍的逻辑实体语义节点的一部分。M2M***可以由本体处理器处理、管理和以其它方式使用本体。

·语义储存库将常规资源的语义信息存储在某些表示中，其可以具有使用RDF的选项。

·规则储存库存储用于表示新知识的规则，这些新知识通常超出与资源数据库中的资源相关联的现有语义。规则通常是条件语句：if-then子句。

·推理机从规则储存库以及语义储存库中的现有资源语义信息接收输入，并且如果满足规则中的条件，则生成新的资源语义信息。新的资源语义信息被添加到语义储存库。

·语义查询处理器处理来自客户端的查询，以搜索存储在语义储存库中的知识/资源语义信息，并将结果返回给客户端。

关于如关于上面图11讨论的健身房用例：

·语义储存库可以存储关于健身房会员、健身房中的设备和由设备产生的数据的语义信息。

·当会员想基于可用性、功能等选择跑步机使用时，可能需要基于语义的查询服务。

·规则储存库可以存储诸如如果会员具有高级会员资格则被授予使用某些机器的规则，则推理机可以使用该规则将新的语义信息添加到资源(例如人的可访问设备)。

·健身房用例中，上面所示的语义支持的功能可以托管在网关704上。

图35是图示实现由其TS 102 690中的ETSI定义的ETSI M2M架构的通信***120的图。注意，该图用于帮助理解本公开，并且被简化以描述本文公开的主题。如图35所示，***120可以包括多个网络域，例如网络域122、网络域130、网络域135和网络域138。每个网络域可以包括网络服务能力层(NSCL)，例如NSCL 126、NSCL 131、NSCL 136和NSCL 139。每个NSCL可以分别与相应的网络应用(诸如网络域122和网络域130中的网络应用127和网络应用132)接口连接。

如进一步所示，诸如网络域122的网络域还可以包括一个或多个设备，诸如设备145(其例如可以是在图1的患者监视应用中使用的M2M设备之一)和一个或多个网关(例如网关140)。在3GPP用语中，设备和网关是UE的示例。如图所示，设备145可以运行设备服务能力层(DSCL)146，其通过由架构定义的mId参考点与NSCL 126通信。设备应用(DA)147也可以在设备145上运行，并且它可以通过dIa参考点与DSCL 146通信。类似地，网关140可以实现通过mId参考点与NSCL 126通信的网关服务能力层(GSCL)141。在网关140上运行的网关应用(GA)142可以经由dIa参考点与GSCL 141通信。通常，dIa参考点允许设备和网关应用与它们各自的本地服务能力(即，分别在DSCL或GSCL可用的服务能力)通信。mId参考点允许驻留在M2M设备(例如，DSCL 146)或M2M网关(例如，GSCL 141)中的M2M SCL与网络域(例如，NSCL126)中的M2M服务能力通信，反之亦然。

仍然参考图35，更详细地，NSCL 126可以在域122中并且在M2M服务器平台125上配置有网络应用(NA)127。NA 127和NSCL 126可以经由参考点mIa 128进行通信。mIa参考点可以允许NA来访问来自M2M域中的NSCL可用的M2M服务能力。

通常，设备145、网关140和M2M服务器平台125包括计算设备，例如图60C、图60D所示的设备，并如下所述。NSCL、DSCL、GSCL、NA、GA和DA实体通常是以软件的形式实现的逻辑实体，在底层设备或平台上执行以在***120中执行它们各自的功能。

如图35进一步所示，NSCL 131可以在具有NA 132的域130中。NA 132和NSCL 131可以经由参考点133进行通信。在网络域135中还可以存在NSCL 136，并且在网络域138中还可以具有NSCL 139。mIm参考点123可以是允许不同网络域中的M2M网络节点(例如网络域122中的NSCL 126、网络域130中的NSCL 131、网络域135中的NSCL 136或网络域138中的NSCL139)彼此通信的域间参考点。为了简单起见，术语“M2M服务器”可以用于指示服务能力服务器(SCS)、NSCL、应用服务器、NA、或MTC服务器。此外，如本文所讨论的，术语用户设备(UE)可以应用于GA、GSCL、DA或DSCL。如本文所讨论的，UE可以被认为是移动站、固定或移动用户单元、寻呼机、蜂窝电话、个人数字助理(PDA)、智能电话、膝上型计算机、上网本、个人计算机、无线传感器或致动器、消费电子产品等。如本文所讨论的机器对机器服务能力层实体可以包括M2M服务器或UE。

I.具有语义节点的M2M架构

图36中图示了包括语义节点的M2M***的一个示例。如M2M***150中所示，语义节点被部署在三个级别。可以存在区域级别，其可以包括诸如区域网络154、区域网络155、区域网络156和区域网络157的网络。可以存在接入级别，其可以包括网络，诸如接入网络152和接入网络153。并且可以存在核心级别，其包括诸如核心网络151的网络。

如***150所示，应用158可以经由参考点sIc 159与位于区域网络157中的M2M语义节点160通信地连接。该sIc参考点通常由应用、该区域中的其它非语义节点实体、接入网络和核心网络实体使用与语义节点通信。M2M语义节点160通过参考点sIe 162与外部语义节点163通信地连接。M2M***中的语义节点可以经由sIe参考点与外部语义节点接口连接。外部语义节点可以管理其它现有语义相关资源，例如由RDFS为语义web定义的那些资源。M2M语义节点160还经由sIs参考点161与位于接入网络153中的M2M语义节点164通信地连接。MME语义节点164经由sIc参考点166与M2M网关165通信地连接，并且经由参考点sIs与位于核心网络151中的M2M语义节点168通信地连接。在该示例中，M2M网关165本身不是语义节点，但是在其它示例中，M2M网关165可以并入语义节点的功能。

为了卸载、负载平衡、容易访问等目的，可以在区域级别部署语义节点。在区域级别，如果在局域网中的所有设备与所附接的接入或核心网络中的语义节点通信，则可能没有部署语义节点。区域级别的语义节点可以在访问级别(例如，与M2M语义节点164连接的M2M语义节点160)或核心级别(例如，与包括语义节点的M2M服务器170连接的M2M语义节点169)具有对应的父语义节点。语义节点通过sIs参考点相互通话。在下文中进一步定义参考点的细节。访问级别的语义节点也可以在核心级别具有父节点，其在sIs参考点上与其通话。同样，在访问级别的语义节点可以在区域级别具有子语义节点，其经由sIs参考点进行通话。核心级别的语义节点也可以在访问或区域级别具有子语义节点。

除了图36中所示的父子关系之外，语义节点还支持在任何语义节点级(例如，访问、区域或核心)处的兄弟的概念。兄弟语义节点是在层级中的相同级别的节点，并且可以用于分布语义节点的负载。例如，在核心网络151中，M2M语义节点168与包括语义节点的M2M服务器170连接。从垂直的角度来看，如果存在多个语义节点的已建立的层级，则节点可以经由通知、广播、发现等在sIs参考点上彼此通话并共享语义信息。

对于受限设备，由于容量的限制，导致语义可以是引用特定语义的代码或指向存储在远程语义节点中的语义的链接。可以由创建数据的应用或由服务层提供这样的语义信息。

在接入级别，可能在一个接入网络中部署一个或多个语义节点。如果如此，则兄弟可以通过sIs参考点彼此通信以进行语义信息通知、广播和发现。访问级别的语义节点也可以具有在核心级别的父，其在sIs参考点上与该父通信。同样，访问级别的语义节点可以在区域级别具有子语义节点，其经由sIs参考点与子语义节点通话。

在核心级，可以在核心网络中部署一个或多个语义节点。这些节点可以是兄弟，并且通过sIs参考点彼此通信，以使用通知、广播和发现来共享语义信息。核心级别的语义节点也可以在访问或区域级别具有子语义节点。区域网络中、接入网络和核心网络的应用、其它非语义节点实体通过sIc参考点与语义节点通话。

如上所述，语义节点可以是网络中的独立物理节点(例如，独立M2M语义节点160)，或者它可以是在网络中的另一物理节点上托管的逻辑实体，诸如M2M设备171、M2M网关172或M2M服务器170，如图36的***150所示。换句话说，M2M设备、M2M网关和M2M服务器可以支持语义节点功能。

图36中所示的多层语义节点层级的特征在于它可以提供不同级别的抽象。语义节点可以仅负责管理局部区域中(诸如在M2M区域网络中)的语义相关资源，使得可以在本地找到区域网络特定语义相关资源。可以在较高级父或平行兄弟节点语义节点中存储并且找到不典型在局部区域中的任何语义相关资源。另一个特征是语义相关资源可能由于互联网层级、位置层级等而具有层级。因此，多层语义与现有网络架构相一致。另外，语义节点可以分布在每个级别中，其避免了如果集中式语义节点仅部署在核心网络中的单个故障点。

II.语义节点架构

现在将讨论关于语义节点的架构的更多细节。如上所述，语义节点存储和管理语义相关资源。如本文所定义的，语义相关资源包括可以用于描述事物的语义信息的信息(诸如由M2M设备或应用生成的数据或M2M设备或应用本身的含义)。在一个示例中，语义相关资源可以使用诸如XML模式定义(XSD)、RDF模式/Web本体语言(RDFS/OWL)等的现有模式以可扩展标记语言(XML)来表示。在示例中，在语义节点中可以存储三种类型的语义相关资源——类、关系和词项-——下面将更全面地描述其中的每一种。以这种方式对语义相关资源的分类提供了与语义Web的当前技术的兼容性。这种兼容性使得M2M***能够利用现有语义相关资源，例如由W3C定义的那些核心类和核心属性。M2M***外部的应用和实体能够使用由语义节点托管的语义相关资源，而不会由于使语义兼容所必需的格式转换或修改而招致任何附加开销。

类。这里讨论的是M2M域中对象/事物的类的概念。在图1的示例性健康监视***中，例如，与***相关的对象的类包括患者、医生、救护车调度员、血压、核心温度、氧饱和度、运动加速度计等。类可以由统一资源标识符(URI)或统一资源定位符(URL)来识别。类包含包含定义类的信息的字段描述。例如，可以用XSD的模式以XML定义作为以摄氏(Celsius)为单位的整数表示温度数据并且可以用于例如将那些语义提供给由温度传感器生成的数据的temperatureReading类，如下：

这里，类包含字段“description”(描述)、“unit”(单位)和“base”(基)，并且这些字段中的信息分别是“摄氏温度”、“摄氏”和“整数”。作为另一示例，BloodPressure(血压)类可以包含两个字段，一个用于收缩压，另一个用于舒张压。该BloodPressure类的类描述将包括两个字段的描述，并且可以使用XML/XSD表达如下：

同样，然而，应当理解，类(以及其它类型的语义相关资源——关系和词项)不限于使用XML/XSD的表达，而是可以以多种合适的描述语言(包括例如，RDFS/OWL等)中的任一种来表示。类也可以彼此相关。例如，“血压”可以是“生命体征(vitals)”的子类，或者等同地，“生命体征”可以是“血压”的超类。子类/超类关系定义类的层级。通常，如果A的每个示例也是B的示例，则A是B的子类。类可以具有多个超类。

关系。关系是一种特殊的语义相关资源。关系描述语义相关资源之间的关系，例如“由……创建”、“生存期”、“由……订阅”等。关系也可以通过URI/URL来识别，其给出了M2M域的关系的全局和唯一的命名方案。类和继承在其它计算领域中是已知的，例如在面向对象编程中。但是虽然有相似之处，但也存在差异。在面向对象编程中，对象类定义了适用于它的关系或属性。向类添加新关系或属性意味着修改类。然而，在这里，关系是全局定义的，也就是说，它们不会作为类定义中的属性封装。可以定义应用于现有类的新关系，而不改变类本身的定义。像类一样，关系也可以彼此相关。例如，“能量模式”和“使用模式”是“模式”的子关系。如果设备具有电气的“能量模式”和手动的“使用模式”，则其具有电气和手动的“模式”。

词项。词项是在M2M域中通常使用的概念。如本文所定义的，词项是可以由许多方使用以描述资源的语义的值。词项的定义可以在其被公布的某些领域中被普遍承认。例如，手动、用户指导和自主的每个都是可用于描述例如设备的使用模式的词项的示例。一般来说，语义相关资源的创建者将确定语义相关资源是否是类、关系或词项。语义节点然后将语义相关资源存储在由它们的创建者定义或确定的类下。例如，在图1的患者监视示例中，语义相关的资源类、关系和词项可以由血压监视器制造商、医生或另一电器制造商创建。在其它示例中，语义相关的资源类、资源和词项可以由垂直应用来定义或创建。

可以由包括资源、关系和值的资源-关系-值三元组描述资源(包括数据、事物等)的语义。值可以是类、词项或其它资源。下面是一些示例，

·内容实例(资源)hasType(关系)temperatureReading(类)

·电器(资源)hasUsageMode(关系)user-directed(词项)

·内容实例(资源)generatedBySameApplicationAs(关系)另一个内容示例(资源)

通过所提出的sIc、sIs和sIe参考点，可以做出对语义节点的类、关系和词项资源的请求。图37是M2M语义节点的类、关系和词项资源的示例性图示。如该示例中所示，语义节点420可以被配置为存储来自不同应用和域的各种类422、关系424和词项426。替选地，语义节点420可以被配置为存储用于唯一应用或域的类、关系和词项资源(诸如器件语义、车辆语义、健康护理应用语义等)。

III.M2M语义节点功能和参考点

在本部分中，提供了关于语义节点的功能和参考点的进一步细节。在一个示例中，语义节点可以执行以下功能：认证其它语义节点，其包括在语义节点层级中认证较低级子级或并行平行兄弟语义节点，以允许它们注册并请求语义节点的资源；认证应用、设备和/或用户以允许它们发布、创建、删除、更新和检索语义相关的类、关系和词项资源；存储和管理语义相关类、关系和词项资源；提供对语义相关资源的发现的支持；并且为语义节点提供支持以彼此(父-子、兄弟之间)之间进行以在发现查询和共享语义相关资源信息上进行协作。

语义节点可以经由一个或多个参考点或接口与网络中的其它实体通信。在一个示例中，定义了三个参考点——sIs参考点、sIc参考点和sIe参考点。sIs参考点用于语义节点之间的通信。语义节点还可以使用sIs参考点来注册到另一语义节点以形成父子关系或兄弟关系，以发现其它语义节点，以将其状态(例如，在线、离线、重载等)通知其它人，以触发另一语义节点执行特定操作(例如，注销、注册)，以在另一语义节点中发布、创建、删除、更新和检索语义相关资源。另外，语义节点可以使用sIs参考点来订阅到另一语义节点中的语义相关资源，并接收相应的通知，以发现其层级中的兄弟和父语义节点中的语义相关资源，以将一组语义相关资源从一个语义节点移动到另一语义节点、并且以允许存储在另一语义节点中的语义相关资源与资源链接并且相关联以向该资源提供语义，如下面结合图53、图54、图55进一步描述的。

在本示例中，sIc参考点可以由应用或非语义节点用于与来自各种网络域(例如，区域网络、接入网络或核心网络)的语义节点进行通信。sIc参考点还允许应用或非语义节点在语义节点中发布、创建、删除、更新、检索、订阅或发现语义相关资源，并从语义节点接收通知。另外，sIc参考点允许将存储在语义节点中的语义相关资源与资源链接和相关联，以向该资源提供语义。

sIc参考点可以用于作为M2M***中的节点的现有层级的一部分的语义节点与外部语义节点之间的通信。外部语义节点存储M2M域之外的语义相关资源。外部语义节点的一个示例可以是如http://www.w3.org/2005/Incubator/ssn所述，存储用于由W2C语义传感器网络孵化器组(W2C Semantic Sensor Network Incubator Group)定义的语义传感器网络本体(Semantic Sensor Network Ontology)的语义相关资源的服务器。sIe参考点允许语义节点在外部语义节点中检索、发现和订阅语义相关资源，反之亦然。同样经由参考点，外部语义节点可以发现M2M***中的语义节点并接收通知。

与sIs、sIe和sIc参考点相关联的消息(其有效地定义那些参考点)的一个示例在下面的表16中阐述。

表16列出了语义节点相关消息、其相应含义以及所使用的参考点。

表16：语义节点消息

诸如超文本传输协议(HTTP)或约束应用协议(CoAP)的协议可以用作用于承载不同类型的消息的基础传输协议。下面给出了使用这些消息来执行上面讨论的各种语义节点功能的示例。

IV.M2M语义节点过程

A.构建语义节点层级

在本部分中，根据一个示例，提供关于如何可以建立语义节点的层级(以下称为“语义节点层级”)的附加细节。在该示例中，通过确定位于网络中不同区域、访问和核心级别的语义节点之间的父子关系和兄弟关系来构建语义节点层级。

图38A是图示用于建立语义节点层级的方法的一个示例的流程图。当语义节点加入网络(步骤504)(即变为在线)时，在它可以变成网络中的可操作语义节点之前，它需要首先构建子-父和兄弟关系。为此，在步骤506中，语义节点可以执行在相同级别中的兄弟语义节点的发现。

兄弟语义节点的发现可以基于发出语义节点发现请求(例如，多播、广播、任播)，其中可以发出发现请求以试图发现兄弟语义节点。该请求可以具有限制发现请求和响应消息的洪泛(这可能拥塞网络)的定义的跳跃限制。替选地，如果可用，则该发现可以利用网络内可用的现有发现机制(诸如域名***(DNS)、DNS服务发现(DNS-SD)、服务定位协议(SLP)等)。语义节点可以存储相邻兄弟语义节点的返回信息(诸如所管理的语义信息的IP地址或类型)。如下面进一步讨论的，兄弟语义节点发现响应消息还可以背负较高级语义节点发现服务器的地址、兄弟的父语义节点的地址或两者。

仍然参考图38A，在发现兄弟语义节点之后，语义节点可以接下来在步骤508、步骤510和步骤512中尝试发现更高级语义节点和/或向更高级语义节点注册。如果语义节点被提供给其需要注册的更高级节点，则它可以简单地向这个提供的语义节点注册并建立父子关系(步骤508、步骤512)。否则，语义节点需要发现现有的较高级语义节点，并选择其中之一来注册(步骤510)。该选择可以基于诸如在相邻上层中最近、支持相同类型的语义资源等的准则。图38B更详细地图示了这些步骤508、步骤510和步骤512。

在本示例中，在每个级别，可以存在一个语义节点发现服务器，其默认地接受更高级语义节点发现请求。语义节点发现服务器的地址对于较低级语义节点可以是公知的。如图38B所示，如果新的语义节点未被提供更高级的父语义节点地址(步骤602)，并且如果新语义节点没有被提供上层中的语义节点发现服务器(步骤604)，则可以首先执行兄弟语义节点发现606。作为兄弟发现的一部分，可以共享(例如，在从发现的兄弟语义节点接收的兄弟发现响应中背负)语义节点发现服务器的地址(步骤608)。另一方面，它还可以显式地请求兄弟的父语义节点信息(地址)，使得它可以选择一个作为其要注册的自己的父(步骤610、618)。

如果新语义节点被提供较高级语义节点发现服务器的地址，则它可以直接执行语义节点发现(控制从步骤604通过到步骤614)。否则，它决定其是否想要从兄弟的父列表中选择以及它是否想要从兄弟中检索默认语义节点发现服务器的地址(步骤608和610)。如果新语义节点从兄弟的父点选择上级语义节点(步骤618)，则它可以选择不进一步执行语义节点发现。否则，它决定选择语义资源的父的准则(最接近跳数、支持相同类型的语义资源等)(步骤614)。基于准则，除了语义节点在较高级别中的地址(距离、支持的语义资源类型等)之外，还设定它想要发现的信息(步骤616)。

在步骤620处，新的语义节点可以向它发现或以其它方式选择的更高级父语义节点注册。如果新的语义节点既不能学习更高级语义节点发现服务器的地址，也不能识别其可能注册的其兄弟的任何更高级父语义节点，则可以确定没有更高级父语义节点并且在步骤612处结束该过程。

返回参考图38A，一旦兄弟的发现以及与父节点的发现和注册完成，就存储关于新的语义节点的兄弟和父的信息(步骤514)。如图38A中进一步所示，如果新的兄弟加入网络或者现有的兄弟离线，则语义节点可以更新它的语义节点关系(步骤516、518)。在步骤520处，新的语义节点现在是操作的。如图38A中进一步所示，可稍后触发操作的语义节点以注册到另一较高级节点(步骤522)，或其可离开网络(步骤526)。在前一种情况下，语义节点可以向其当前父注销，并向新的父注册(步骤524)。在后一种情况下，语义节点可以简单地向其当前父注销(步骤528)。

图39是进一步图示以上讨论并在图38A、图38B中图示的语义节点发现和注册过程的消息流程图。在步骤185处，新语义节点181向兄弟语义节点182发送语义节点发现请求。兄弟语义节点182与新语义节点181在相同的网络级中。步骤185的语义节点发现请求可以包含对关于语义节点发现服务器183的信息(例如，地址)或者对作为兄弟语义节点182的父(例如，上层)语义节点184的语义节点的信息的请求。对父语义节点的请求可以允许新的语义节点181选择向自己的父节点注册。

语义节点发现服务器183可以被认为是用于存储散布在相同级别或会合点中的语义节点的信息的集中点、或集合(rendezvous)点，以在网络的相同级中洪泛发现请求，并且收集语义节点的返回响应。语义节点发现服务器183可以是驻留在比新语义节点181的网络级更高、相同或更低级别的网络级别的网络中的服务器。该示例假设语义节点发现服务器183处于关于新语义节点181的网络级别的上级。语义节点发现服务器183的地址对于较低级语义节点(例如，兄弟语义节点182)是众所周知的。如果新语义节点181未被提供语义节点发现服务器183，则新语义节点181可以执行兄弟语义节点发现。如果向新语义节点181提供语义节点发现服务器183的地址，则它可以直接执行语义节点发现。

在图39的步骤186处，兄弟语义节点182发送语义节点发现响应。语义节点发现响应可以包含语义节点发现服务器183的信息(例如，地址信息)或者作为兄弟语义节点182的父的语义节点的信息。web的级别中的每个兄弟节点可以用父语义节点信息和语义节点发现服务器信息进行响应，其可以不同于由兄弟语义节点182提供的信息。

在步骤187处，新语义节点181提取语义节点发现服务器183的接收地址。在步骤188处，新语义节点181向语义节点发现服务器183发送语义节点发现请求。在步骤188处的请求可以是对新语义节点181可以连接的一个或多个父语义节点的查询。在步骤189处，语义节点发现服务器183向新语义节点181发送语义节点发现响应。在步骤189处的响应可以包含一个或多个父语义节点。在步骤190处，新语义节点181选择一个父语义节点来向其注册。在步骤191处，语义节点181发送向其选择的父语义节点184进行注册的请求。在步骤192处，父语义节点184发送对在步骤191的注册请求的响应。

通常，如果向新语义节点181提供语义节点发现服务器183的地址，则它可以直接执行语义节点发现。否则，新语义节点181决定它是否想从来自一个或多个兄弟节点接收的父语义节点的列表中进行选择，以及它是否希望从兄弟中检索语义节点发现服务器183的默认地址。在每个级别，可以存在一个或多个语义节点发现服务器，其默认地接受更高级语义节点发现请求。如果新语义节点181从兄弟的父节点选择上级语义节点，则新语义节点181可以选择不进一步执行语义节点发现。新语义节点181可以具有决定选择父节点的准则的选项(例如，从诸如最接近的跳数、支持相同类型的语义相关资源等的选项中选择)。基于该准则，新语义节点181除了上级中的语义节点的地址(例如，语义相关资源的距离、所支持的类型等)之外还设定它想要发现的信息。

图40提供了根据其一个示例的提供父子关系更新过程(例如，图38A的步骤522和524)的进一步细节的消息流。更新可以由子或父语义节点发起。在步骤205处，语义节点201基于通知决定从当前父语义节点203注销。该通知可以是来自当前父语义节点203的用于发起注销的消息，当前父语义节点203不可达的确定(例如，离线、断开连接或其它通信问题)或与父语义节点203相关联的接收的状态更新(例如，网络流量拥塞、设备或线路错误、存储器容量问题)等。

在步骤206处，语义节点201向当前父语义节点203发送注销请求，其包括结束父子关系的请求。在步骤207处，语义节点201可以从当前父语义节点203或能够传达当前父语义节点203的感知状态的另一设备接收在步骤206中发送的注销请求的响应。类似于图39所示的步骤，语义节点201尝试向新的父语义节点注册。在步骤208处，语义节点201向语义节点发现服务器202发送语义节点发现请求。在步骤209处，语义节点发现服务器202向语义节点201发送语义节点发现响应。在步骤210处，语义节点201选择一个将向其进行注册的上级别的语义节点。在步骤211处，语义节点201发送向其选择的新的父语义节点204进行注册的请求。在步骤212处，新的父语义节点204发送对在步骤211处的注册请求的响应，其确认父-子关系的更新。

在示例中(未图示，但是参考图40中的元素)，父语义节点可以触发子的注销，并为子提供用于注册的新的父语义节点。这个新的父信息可以包括在注销触发消息中，或者替选地包括在单独的触发消息中。语义节点201可以通过使当前父语义节点203向新父语义节点204发送注册请求来向新父语义节点204注册。当前父语义节点203具有为了注册目的将语义节点201的信息转发到新父语义节点204的选项。当前父语义节点203或语义节点201可以在将当前父语义节点203切换到新的父语义节点204之前终止父子关系。

一般来说，当子语义节点离线时或当子语义节点注册到另一较高级父语义节点时，通过向当前父语义节点注销来终止语义节点的父子关系。

如果邻近的兄弟语义节点加入网络，则通过添加新的语义节点来更新对应的兄弟信息。如果相邻兄弟语义节点离开网络，则通过删除语义节点或以其它方式更新表以指示离开网络的兄弟语义节点的状态(例如，status＝offline)来更新对应的兄弟信息。语义节点可以使用例如上面在表14中示出的SEMANTICS_NODE_STATUS_NOTIFY()消息来广播或以其它方式将其状态传达给兄弟语义节点。状态更新可以影响如何维持兄弟和父子关系。

B.语义相关资源发现、检索和验证

应用、设备、用户、对等体语义节点、外部语义节点或非语义节点可以通过sIc、sIs和sIe参考点将语义相关资源发现请求发送到语义节点。发现请求消息可以包括语义相关资源的类型(类、关系或词项)和搜索字符串。例如，假设在M2M***中的温度感测应用(App1)，该温度感测应用需要将其温度读数数据(作为以摄氏度为单位的整数)报告给其M2M网关。为了使网关服务能力层(GSCL)能够理解数据，App1需要将数据与正确的语义信息相关联。根据本文描述的过程，App1可以发现存储语义相关资源类的语义节点——temperatureReading类，其将温度数据表示为以摄氏度为单位的整数。在发现后，App1将检索temperatureReading类的表示，并验证这是其想要使用以为其温度数据提供语义的对象。然后它将数据与temperatureReading类链接作为其属性之一(语义属性)。在GSCL中，数据可以存储在App1的<tempData>容器下，该容器将具有使用hasType关系链接到temperatureReading类的语义属性，如图59中示例所示。因此，存储在GSCL中的<tempData>容器下的所有App1数据将具有相同的语义——每个数据项是整数并且具有摄氏度单位。作为另一示例，App1可以是从NSCL检索资源的应用。资源可以具有链接到temperatureReading类的语义属性(类似于上述示例)。为了理解和解释资源的容器中的数据，App1将需要检索与资源的语义属性链接的语义相关资源——在本例中是temperatureReading类。在App1检索temperatureReading类语义相关资源的表示之后，它将能够解释资源数据——它现在知道资源数据是整数且具有摄氏单位。

图41是图示根据一个示例的语义节点处语义相关资源发现请求的处理的流程图。在框221处，语义节点接收包括所请求的语义相关资源的类型和潜在搜索字符串的语义相关资源发现请求。在框222处，语义节点检查发现请求。如果请求不足或畸形(例如，丢失所请求的资源的类型)，则发现请求被认为是无效的，并且无效的发现响应将被返回给发出者(例如，请求客户端设备)，如框233所示。如果请求有效，如框223所示，则将搜索字符串与本地存储的语义相关资源进行比较。具体地，基于所请求的语义相关资源的类型，语义节点能够确定它将搜索哪种类型(即，类、关系或词项)的语义相关资源。如框224所示，使用搜索字符串作为关键字，语义节点搜索其本地语义数据库以找到一个或多个匹配语义相关资源。如果在本地找到匹配的语义相关资源，则在发现响应中将语义相关资源的地址(例如，URL/URI)返回给发出者，如框225所示。

如果在本地找不到匹配的语义相关资源，则语义节点将尝试从其兄弟语义节点找到匹配的语义相关资源。如框226和框227所示，语义节点将发现请求转发给兄弟，并设定它将等待响应返回的时间窗口。在框228处，确定是否从所联系的兄弟中找到匹配的语义相关资源。如果从其兄弟中返回匹配的语义相关资源，则使用成功的发现响应将语义相关资源的相应地址(例如，URI/URL)发送回发出者(方框225)。

如果没有从语义节点的兄弟节点返回的匹配的语义相关资源，则如框229所指示，确定是否可以联系父语义节点。如果没有父语义节点，则将指示否定结果的发现响应返回给发出者(框233)。如果存在父语义节点，则语义节点将尝试从其父语义节点找到匹配的语义相关资源。如分别由框230和框231所指示的，语义节点将发现请求转发到父语义节点并设定它将等待响应返回的时间窗口。在框232处，确定是否从所联系的父找到匹配的语义相关资源。如果从所联系的父返回匹配的语义相关资源，则使用成功的发现响应将语义相关资源的对应地址(例如，URI/URL)发送回发出者(方框225)。如果没有从语义节点的父返回的匹配的语义相关资源，则将向发出者返回指示否定结果的发现响应(框233)。

在发出者接收到包含匹配的语义资源的地址(例如，URL/URI)的成功发现响应之后，发出者可以检索语义资源的表示。

在一个示例中，语义节点可以支持由客户端和服务器组成的RESTful架构风格(表示性状态转移)。客户端(例如，发出者)向服务器(例如，语义节点)发起语义请求。在该示例中，服务器(例如，语义节点)处理对语义的请求并返回适当的语义响应。请求和响应围绕语义相关资源的表示的传递构建。客户端可以是可以向语义节点请求对语义相关资源(例如，类、关系或词项)的RESTful操作的应用、用户、设备、语义节点等。

当在RESTful架构中处理资源时，有四种可应用于语义相关资源的基本方法：

·创建(CREATE)：创建类、关系或词项资源。

·检索(RETRIEVE)：读取类、关系或词项资源的内容。

·更新(UPDATE)：写类、关系或词项资源的内容。

·删除(DELETE)：删除类、关系或词项资源。

充当RESTful服务器的语义节点可验证接收的请求。如果发出者被授权具有适当的访问权限，则允许操作。

图42是进一步图示根据该RESTful示例的这些RESTful语义节点操作的消息流程图。在步骤243处，发出者241相应地使用RESTful CREATE、RETRIEVE、UPDATE或DELETE动词来请求创建、更新、检索或删除语义相关资源(类、关系或词项)。发出者241可以是应用、另一语义节点、设备、用户等。为了在步骤243处创建语义相关资源，发出者241发出CREATE请求，提供语义相关资源的类型和表示。为了在步骤243处更新语义相关资源，发出者241发出UPDATE请求，提供唯一标识或地址以及语义相关资源的更新的或部分更新的表示。为了在步骤243处检索语义相关资源，发出者241发出RETRIEVE请求，提供语义相关资源的唯一标识或地址以及可选的searchString(搜索字符串)参数。为了在步骤243处删除语义相关资源，发出者241发出DELETE请求，提供语义相关资源的唯一标识或地址。

在步骤244处，语义节点242充当服务器并验证并以其它方式处理所接收的请求。如果发出者241被授权具有适当的访问权限，则允许接收到的请求。如果语义节点242允许创建操作，则基于新的语义相关资源是类、关系还是词项，在适当的资源池下创建新的语义相关资源。且通过语义节点242向语义相关资源分配唯一的标识或地址。如果语义节点242允许更新操作，则更新语义相关资源的表示。如果语义节点242允许检索操作，则以发出者241请求的格式准备语义相关资源的表示。如果语义节点242允许删除操作，则删除所请求的语义相关资源。

在步骤245处，语义节点242向发出者241返回响应。对于创建操作，将新创建的语义相关资源的标识或地址返回给发出者。对于更新操作，向发出者241返回操作是否成功的响应代码。对于检索操作，将语义相关资源表示以发出者241请求的格式返回给发出者241。对于删除操作，将响应代码返回给发出者241以指示操作是否成功。

图43是进一步图示本文描述的语义相关资源发现、检索和验证过程的消息流250。在该示例中，网络可以包含发出者251、语义节点252、作为语义节点252的兄弟的兄弟语义节点253、以及作为语义节点252的父的父语义节点254。在步骤256处，发出者251向语义节点252发送语义相关资源发现请求。如消息流250所示，语义节点252经过若干步骤(类似于图41中的过程)以找到与在步骤256处的请求匹配的语义相关资源。如图所示，首先语义节点252将搜索其本地目录。如果它没有找到任何匹配的资源，则它将建立时间窗口并将发现请求转发给它的兄弟，例如兄弟253。如果没有从其兄弟接收到响应，则语义节点252可以将其请求转发到父语义节点254。在该示例中，假设父语义节点254找到了匹配的资源，并且它将向语义节点252发送回指示语义相关资源的地址(例如，URI/URL)的响应。

在步骤257处，语义节点252然后将语义相关资源发现响应发送回发出者251，其包括来自父语义节点254的与发出者的请求匹配的语义相关资源的地址(例如，URI/URL)。在步骤259处，发出者251基于接收到的URL发送语义相关资源检索请求。在步骤260处，父语义节点254发送包含所请求的语义信息的语义相关资源检索响应，其可以包括类、关系或词项。

在步骤261处，发出者251从步骤260检查(验证)所接收的语义信息的表示。存在接收的在步骤260处发送的语义相关资源不是发送者251想要的东西的可能性。例如，如果发出者251请求温度类并且返回的匹配的资源是具有关联的华氏单位的称为temperatureReading的类，但是发出者251期望单位为摄氏的温度类，则发出者251可以请求父语义节点254修改语义。这可以通过在步骤262处向父语义节点254发送语义相关资源修改请求以修改语义相关资源来支持。在步骤263处，将把新添加的或修改的语义相关资源的地址(例如，URL/URI)返回给发出者251。

参考语义相关资源的修改，一般来说，如果语义节点本身不支持修改，则语义节点可以与其兄弟或父协作以执行修改。如果语义节点支持修改，则语义节点可以通过添加新类或扩展当前类来本地修改类。

C.语义相关资源

在一个示例中，语义节点可支持订阅到它的客户端(例如，应用、另一语义节点、设备、用户等)。作为一个示例，客户端可以订阅到语义节点，以在对订阅到的语义相关资源的任何更新时被通知。当发生更新时，将使用资源的新表示通知订阅客户端。在客户端是语义节点本身的情况下，订阅的语义相关资源可以存储在订户语义节点与其无关(例如，不是父-子或兄弟)的另一语义节点中。在该示例中，客户端可以向语义节点发出SEMANTICS_RESOURCE_SUBSCRIBE_REQ消息。该消息识别当资源被更新时客户端希望接收通知的语义相关资源。语义节点将使用应答订阅的SEMANTICS_RESOURCE_SUBSCRIBE_RESP消息来响应请求。当客户端订阅到的语义相关资源被更新时，语义节点将发送SEMANTICS_RESOURCE_SUBSCRIBER_NOTIFY消息以通知客户端更新。

作为另一示例，语义节点可能对正使用由其兄弟、父或子语义节点之一存储和管理的语义相关资源进行更新感兴趣。图44是根据一个示例的针对这种情况的订阅/通知过程的示例性流程270。在该示例中，使用由订阅到的语义节点272存储和管理的语义相关资源更新语义节点271。订阅到的语义节点272可以是语义节点271的兄弟、父或子节点。在步骤273处，语义节点271识别订阅目标并且可以设定通知触发准则，使得其仅接收与触发准则相关的语义相关资源通知。例如，订户可以配置通知触发准则以指定特定语义相关资源或在发送新通知之前语义相关资源的特定数量的更新。语义节点271还可以设定何时应当发送通知的时间段调度信息。

在步骤274处，语义节点271向目标语义节点272发送语义节点资源订阅请求。在步骤275处，目标语义节点272确定是否接受步骤274的语义订阅请求。目标语义节点272可以基于现有订户、处理所述订阅的负载(例如，关于收集更新信息的负载或用于发送通知的带宽)等决定是否接受订阅请求等。在步骤276处，目标语义节点272向语义节点271发送语义节点订阅响应。在步骤276处的响应可以包括订阅的确认和将在处理该订阅中使用的参数。在步骤277处，在步骤276之后的某个时间点，目标语义节点272检测与在步骤274处接收的请求的触发匹配的语义通知触发条件。在步骤278处，目标语义节点272发送语义节点资源订阅通知消息以关于特定语义相关资源更新语义节点271。

一般来说，语义相关资源订阅可以促进来自对等语义节点或父语义节点的语义相关资源发现。例如，基于通知消息(其将包括存储在语义节点上的新创建的或更新的语义相关资源的URI)，语义节点可能能够在不发送发现请求的情况下执行对其它节点的语义相关资源的发现。

D.语义相关资源的链接和关联

可以以各种方式使用语义节点的语义相关资源。例如，可以从语义节点检索语义相关的资源表示，并且可以以协同定位的方式在其中存储数据的网络位置中(例如，在网络服务器上、在设备上、在网关上等等)存储语义相关的资源表示。替选地，资源的语义可以存储在语义节点上，并且到语义的链接可以与数据一起共存并存储。可以在数据内内嵌(in-line)(即，嵌入)存储该语义链接，或者其可以与数据旁边分开地存储(例如，在单独的资源或属性中)。因此，通过这种到语义相关资源的链接，语义可以应用于M2M***中的常规资源(例如，<SCL>、<application>、<container>等)。通常，在创建资源时，将由资源创建者/生成者创建此链接。

继续图1中的患者健康监视应用的较早示例，存在在语义节点上定义的语义类，并且这些类的URL可以由患者健康监视应用发现。表17图示了与患者健康监视应用相关的类型“类”的语义相关资源的示例。数据可以使用称为hasType的语义关系链接到这些语义类。因此，对于具有为example/healthmonitoring/data1的URI的每个数据资源，将通过以下关联知晓资源的语义：

·example/health/patient/data1 hasType semanticsNode1/class/patient

·example/health/doctor/data2 hasType semanticsNode1/class/doctor

·example/health/bp/data1 hasType semanticsNode1/class/bloodpressure

·example/health/temp/data1 hasType semanticsNode1/class/temperature

·example/health/hr/data5 hasType semanticsNode1/class/heartrate

还可以由参考存储在语义节点上的hasType关系的语义描述的URL/URI来识别hasType关系。

表17：类语义相关资源的示例

E.分组优化

如果集合资源具有一些类似的语义(例如，相同应用中的所有资源具有相同的语义)，则类似语义可以应用于应用，而不是应用于该应用下的每个单独资源。图45图示了根据其一个示例的对具有相同语义的资源进行分组的方法281。在步骤281处，确定同一应用的一些现有数据共享相同的语义关联。在步骤282处，将共享相同语义的同一应用程序中的确定数据分类为组。在步骤283处，步骤282的每个组与适当的语义相关联。在步骤284处，将来自相同应用的新接收的数据放入共享相同语义的组中。相同应用的现有数据可以被分类为多个组，每个组共享相同的语义链接和关联。如果从同一应用程序生成新数据，则将数据放入共享相同语义的组中。

例如，血压监视数据的多个实例具有相同的语义。因此，每个实例可以与相同的语义(semanticsNode1/class/bloodpressure)相关联，如下所示：

·example/health/bp/data1 hasType semanticsNode1/class/bloodpressure

·example/health/bp/data2 hasType semanticsNode1/class/bloodpressure

·example/health/bp/data3 hasType semanticsNode1/class/bloodpressure

通过支持此分组优化，以下关联也可能有效：

·example/health/bp hasType semanticsNode1/class/bloodpressure

F.推送语义相关资源

如上所述，可以被其它语义节点发现和使用托管在语义节点中的类、关系和词项。基于请求的频率，为了更容易的发现和访问，可以将语义相关资源中的一些推送或镜像到另一语义节点中。例如，在一个语义节点检测到来自另一语义节点的相同的转发的发现请求一定次数(例如，超过策略定义的阈值)之后；它可以决定将语义相关资源的镜像副本推送到该语义节点。

语义相关资源推送可以发生在兄弟之间、或者父和子语义节点之间，如图46所示。例如，在核心网络中图46的语义节点291可以从语义节点292、语义节点293和语义节点294接收针对相同语义相关资源(例如，温度)的许多发现和检索请求。当发现请求达到定义的阈值时，语义节点291可以决定在语义节点292上创建相同的语义相关资源(即，对资源进行镜像)，使得语义节点293和语义节点294可以以更快的响应时间访问语义相关资源。语义节点291可以通过向该另外语义节点发出SEMANTICS_RESOURCE_CREATE_REQ消息来在该语义节点上创建镜像资源，然后该另外语义节点将使用适当的SEMANTICS_RESOURCE_CREATE_RESP消息进行响应。

可以使用以下选项以保持语义相关资源是最新的。参考图46，如果对语义相关资源的原始表示有任何更新(例如，不需要订阅)，则语义节点291可以自动更新语义节点292上的语义相关资源。替选地，语义节点292可订阅到原始语义相关资源。基于语义节点292对语义相关资源的订阅，语义节点292将被通知对特定订阅语义相关资源的任何改变。还可以存在前述情形的组合。例如，可能存在语义节点291的自动更新针对语义节点291上的所有语义相关资源周期性发生，而语义节点292期望针对特定订阅到的语义相关资源的更即时更新的情况。

语义相关的资源推送可以发生在兄弟之间，或者在父和子之间任一方向上。例如，参考图46，语义节点296可以将一些局部语义相关资源推送到其父语义节点297。在另一个示例中，语义节点291可以将一些更高级语义相关资源推送到其子语义节点298。

G.数据/语义相关资源移动

图47图示了设备从一个网络移动到另一个网络的情形。在这种情况下，为了由于语义资源检索的安全性、开销和/或加载，与设备相关的语义资源和由设备生成的数据也可能需要移动到新位置以。

参考47，设备最初可能已经位于区域网络301中，但是现在已经移动到区域网络302。初始地，设备309与语义节点306通信。在设备309到达区域302之后，设备309可以初始地继续与语义节点306通信，如线303所示。这可以导致接入网络304、接入网络308和核心网络300中不必要的开销。为了解决这个问题和其它问题，语义节点306的语义相关资源可以被移动到区域网络302中的语义节点307。在将语义相关资源移动到语义节点307之后，设备309不需要针对语义相关资源遍历核心网络300，而是现在可以如语句305所指示的那样与语义节点307通信。

图48是进一步图示如图47所示的数据或语义相关资源的移动的示例消息流310。在步骤315处，第一区域网络中的语义节点311与位于区域网络2中的设备应用314交换消息。在步骤315处交换的消息可以包括例如语义相关资源检索请求和语义相关资源检索响应。在步骤316处，语义节点311决定将与设备应用214相关联的语义相关资源移动到位于第二区域网络中的语义节点313。语义节点313可以通信地比第一区域网络更靠近(花费更少的时间到达)或逻辑上更近(例如，更少的跳跃)。参考步骤316，其它设备可以做出移动语义相关资源(诸如语义节点发现服务器312、设备应用314或另一计算设备(未示出))的决定。

在步骤317处，在语义节点311和语义节点发现服务器312之间交换语义节点发现请求和响应以建立语义节点的层级以及兄弟关系。在步骤318处，语义节点311确定语义节点313的地址。在步骤320处，将语义相关资源创建请求消息发送到语义节点313以复制由设备应用314使用的语义相关资源(和其它数据)。语义节点313使用语义相关资源创建响应消息进行响应，其可以包括语义相关资源和其它数据已被成功复制的应答。在步骤321处，将语义链接更新请求消息发送到设备应用314。在步骤321处的消息可以包括设备应用314从语义节点313检索语义相关资源的指令。在步骤322处，语义链接更新响应消息可以包括语义节点链接被更新的应答。在步骤323处，设备应用314从语义节点313检索类、关系和词项的类型中的语义相关资源。

V.ETSI M2M/oneM2M示例

A.具有语义节点的ETSI M2M架构

如上所述，本文所描述的语义节点概念可以用于增强ETSI M2M架构。注意下面的示例(例如，图49-图55)是ETSI示例；这些也可以在oneM2M架构中被合理地转换/实现。在一个示例中，一个或多个语义节点可以作为独立网络实***于接入/核心网络中，其可以被称为如图49所示的M2M语义节点。在图49中，M2M语义节点331和M2M语义节点332位于同一接入/核心网络330中。区域/核心网络330中的M2M语义节点可以经由上述sIc参考点与DSCL、GSCL、NSCL和应用接口连接。另外，M2M语义节点331和M2M语义节点332可以经由参考点334彼此接口连接。M2M语义节点331和M2M语义节点332还可以经由参考点参考另一类型的外部语义节点333。在该示例中，位于接入/核心网络330中的M2M语义节点也可以形成兄弟和/或父子关系。

语义节点可以支持如在当前ETSI M2M架构的服务能力层(xSCL)中使用的补充资源结构，并且该资源结构可以以图50所示的方式应用于本文所述的语义节点。在该示例中，<ssBase>资源341是驻留在托管语义节点上的资源树的根。<ssBase>资源341可以包含描述托管语义节点的属性。<ssBase>资源341包含表示SS资源343、类资源344、关系资源346、词项资源348、访问权限资源349和订阅到资源350等的集合的集合资源。在类资源344下，可能存在作为类资源344的子类的其它<class>资源345。在关系资源346下，可能存在其它<relationship>资源347，其是关系资源的子关系。SS资源集合343包含当远程语义节点向本地语义节点注册或注销时创建或删除的语义节点资源。

如图51所示，SS资源343的集合中的每个语义节点资源可以具有相应的资源结构。这些资源维持注册到本地语义节点的远程语义节点的状态。例如(诸如联系地址信息、发现信息(例如，所通告的语义类、表示和词项资源)和安全信息(例如，用于与相应的远程语义节点通话的凭证)的状态。

再次参考图50，在<ssBase>资源341下的类344、关系346和词项348集合每个可以包含在本地语义节点上托管的语义相关资源的相应实例。每个实例可以包含语义表示以及具有与其相关联的其它属性，诸如发现相关信息(例如标签)。这些语义相关资源的集合可以由具有适当访问权限的客户端访问。在<ssBase>资源341下的访问权限资源349可以包含访问权限资源的实例。这些访问权限资源349可以定义访问权限的实例，其控制哪些客户端被授权访问哪些语义节点所支持的语义相关资源和操作。替选地，可以在资源结构中支持访问权限集合的其它实例，以提供更细粒度的访问控制(图50中未示出)。订阅资源350的集合可以包含订阅资源的实例。订阅资源的实例可以由希望在指定的通知触发准则事件发生时从语义节点接收语义通知的客户端创建。发现资源342支持客户端语义发现请求。这些发现请求可以支持搜索准则(例如，具有特定类型的属性的语义相关资源)。语义节点可以利用与搜索准则(如果有的话)匹配的资源地址(例如，URI)的列表来响应发现请求。语义节点还可以支持将请求转发到其它语义节点(例如，将发现请求转发到子、兄弟或父语义节点)。

B.具有语义能力的xSCL

在图52所示的另一示例中，M2M语义节点可以被部署为ETSI M2M架构的DSCL、GSCL和/或NSCL内的嵌入能力，而不是作为单独的独立语义节点。在该嵌入的示例中，sIs参考点可以保持分离，或者可以增强ETSI M2M mId参考点以支持sIs功能。同样，sIc参考点可以保持分离，或者ETSI M2M mIa和dIa参考点可以被增强以支持sIc功能。在该示例中，位于GSCL或DSCL中的M2M语义节点可以与它们注册到的NSCL建立父子关系。另外，位于GSCL或DSCL中的语义节点也可以彼此建立兄弟关系。

为了支持图52的示例，xSCL可以具有图53所示的资源结构。语义节点的资源集合包含当具有语义节点能力的远程SCL向本地SCL注册或注销时创建或删除的语义节点资源。该集合中的每个语义节点资源可以具有如图53所示的相应的资源结构。这些资源维持注册到本地SCL的远程语义节点的状态。例如，诸如语义发现信息(例如，所通知的语义类、表示和词项资源)等的状态等。

在<sclBase>资源361下的类、关系和词项集合可以各自包含在本地SCL上托管的语义相关资源的相应实例。每个实例可以包含语义表示以及具有与其相关联的其它属性，诸如发现相关信息(例如标签)。这些语义相关资源的集合可以由具有适当访问权限的客户端访问。

C.ETSI M2M语义实施方式的用例示例

由语义节点管理的语义相关资源可以被关联并链接到ETSI M2M资源结构中的资源，例如<sclBase>、<application>、<container>、<contentInstance>等。以下讨论说明可以如何使用语义相关资源来提供<contentInstance>的语义信息。

在本示例中，假设temperatureReading类被定义并存储在scl1上，并且具有scl1/classes/temperatureReading的URI。也在scl1上定义并存储关系hasLocation，并且具有scl1/relationship/hasLocation的URI。此外，术语“northeastChina”也被定义并存储在scl1上，并且具有scl1/terms/northeastChina的URI。图54示出了<scl1>上的语义相关资源结构，其是图53所示的xSCL资源结构的示例。该资源结构确定语义相关资源的URI。contentInstance具有为gscl2/applications/app1/containers/<temperature>/contentInstances/<inst1>的URI。通过用如图55的xSCL资源结构中所示的语义增强contentInstance，可以有效地描述和解释contentInstance的内容而没有歧义。

图56是图示了资源和语义检索的一个示例的消息流。在步骤393处，NA 390向GSCL2 391发送对数据资源的检索请求。数据资源例如可以是血压传感器读数、核心温度传感器读数、氧饱和度传感器读数或运动加速度计传感器读数等。在步骤394处，GSCL2 391返回数据资源的表示。为了理解数据资源，NA需要检索数据资源的语义。因此，在步骤395处，NA 390向GSCL 391发送检索请求。在步骤396处，GSCL2 391返回存储在SCL1 392上的数据资源的相关语义相关资源的URI的列表。在步骤397至399处，NA 390分别针对语义相关资源temperatureReading、hasLocation和northeastChina与SCL1 392交换检索消息。利用这些语义相关资源，NA 390能够理解数据资源，并且因此可以使用和操纵数据资源。

VI.3GPP MTC架构示例

如上面进一步提到的，还可以利用本文描述的语义节点提供的语义支持来增强3GPP MTC架构。如图57所示，在一个示例中，M2M语义节点401可以位于3GPP核心网络边界之外。如进一步所示，可以增强SCS 404以支持语义能力，并且SCS 404可以经由sIs参考点(未示出)与M2M语义节点401接口连接。M2M语义节点401还可以经由sIc参考点403与3GPP机器类型通信互通功能(MTC-IWF)402接口连接。应用服务器(AS)406和AS 407可以经由sIc参考点400与M2M语义节点401通信。图58图示了具有语义节点的3GPP MTC架构的另一示例。在该示例中，语义节点已经被集成到SCS 408中。进一步如图58所示，在409处，在该示例中，sIc参考点可以是3GPP MTC Tsp的一部分。

尽管这里通过背景的方式描述oneM2M、3GPP和ETSI M2M架构，并且oneM2M、3GPP和ETSI M2M架构可以用于说明下文描述的各种示例，但是应当理解，下文描述的示例的实施方式可以变化，同时保持在本公开的范围内。本领域技术人员还将认识到，所公开的示例不限于上面讨论的使用3GPP或ETSI M2M架构的实施方式，而是可以在其它架构和***中实现(诸如oneM2M、MQTT和其它M2M***和架构)。

图60A是示例机器对机器(M2M)、物联网(IoT)或物联网万物网(WoT)通信***10的示图，其中可以实现一个或多个公开的示例(诸如图12或图11)。通常，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、网关或服务平台可以是IoT/WoT的组件以及IoT/WoT服务层等的组件。

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

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

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

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

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

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

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

图60C是示例M2M设备30(例如M2M终端设备18或M2M网关设备14)的***图。如图60C所示，M2M设备30可以包括处理器32、收发器34、传送/接收元件36、扬声器/麦克风38、键盘40、显示器/触摸板42、不可移动存储器44，可移动存储器46、电源48、全球定位***(GPS)芯片集50和其它外设52。应当理解，M2M设备30可以包括前述元件的任何子组合，同时保持与示例一致。该设备可以是使用所公开的用于M2M本体管理和语义互操作性的***和方法的设备。M2M设备30(例如，MOP 721、ODC 723、OPC 726、OCC 724或OR 727、网关704、环境传感器706、血压监视器701、体重计702、发出者741等)可以是执行所公开的用于M2M本体管理和语义互操作性的***和方法的示例性实施方式。

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

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

另外，虽然在图60C中描绘了传送/接收元件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上(例如在服务器或家用计算机上)的存储器访问信息，并且将数据存储在其中。响应于在本文描述的一些示例中的M2M本体管理消息(例如，将本体转换为兼容消息)是否成功(例如，异常处理(EHR)、SLMP或链接简档提交等)，处理器32可以被配置为控制显示器或指示器42上的照明模式、图像或颜色，或以其它方式指示OPC 726、OCC 724、OR 727、ODC 723、或本文的其它与语义相关联的过程和组件的状态。例如，如本文在图20至图23中类似地描述的显示器上的本体的组织。显示器或指示器42上的控制照明图案、图像或颜色可以反映本文中图示或讨论的(例如，图11至图61等)图中的方法流程或组件中的任何一个的状态。本文公开了M2M本体管理和语义互操作性的消息和过程。可以扩展所述消息和过程以提供用户用来经由输入源(例如，扬声器/麦克风38、键盘40或显示器/触摸板42)请求资源相关资源并且请求、配置或查询资源等以用于M2M本体管理和语义互操作性的接口/API，其可以显示在显示器42上。

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

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

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

图60D是其上例如可以实现图60A和图60B的M2M服务平台22的示例性计算***90的框图。计算***90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，计算机可读指令可以是软件形式，无论这种软件被存储在何处、或者通过任何手段访问这种软件。这样的计算机可读指令可以在中央处理单元(CPU)91内执行以使计算***90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的执行附加功能或辅助CPU 91的可选处理器。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于M2M本体管理和语义互操作性的***和方法相关的数据，例如接收本体发布消息。

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

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

另外，计算***90可以包含外设控制器83，外设控制器83负责将指令从CPU 91传送到诸如打印机94、键盘84、鼠标95和磁盘驱动器85的外设。

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

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

图61图示了可以基于本文所讨论的方法和***生成的示例性显示。显示接口1(例如，触摸屏显示器)可以在框2中提供与M2M本体和语义(诸如表1至15的参数)相关联的文本。在另一示例中，本文所讨论的任何步骤的进展(例如，发送的消息或成功)可以显示在框2中。此外，图形输出3可以显示在显示接口1上。图形输出3可以是本体的拓扑、本文所讨论的任何方法或***的进展的图形输出等。

应当理解，本文所描述的***、方法和过程中的任何一个或全部可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实现，其指令当由机器(诸如计算机、服务器、M2M终端设备、M2M网关设备等)执行时，执行和/或实现本文描述的***、方法和过程。具体地，上述任何步骤、操作或功能可以以这样的计算机可执行指令的形式来实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性介质两者、可移动和不可移动介质两者，但是这样的计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁性存储设备或可用于存储所需信息并可由计算机访问的任何其它物理介质。

在描述本公开的主题的优选示例时，如图所示，为了清楚起见采用了特定术语。然而，所要求保护的主题不旨在限于所选择的特定术语，并且应当理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等同物。语义相关资源可以是本体(本体可以由类、关系和词项组成)或者独立的类、关系、词项。

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

Claims (7)

1.一种使用本体储存库组件的机器对机器(M2M)本体处理的设备，所述设备包括：

处理器；和

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

接收本体发布消息，所述本体发布消息包括来自第一命名空间的第一本体；

基于所述本体发布消息，确定所述第一本体是与第二命名空间的格式不兼容的外部本体；

响应于确定所述第一本体与所述第二命名空间的格式不兼容，将所述第一本体转换为兼容格式；

对所转换的第一本体进行分类，其中，所述对所转换的第一本体进行分类包括确定所转换的第一本体所属于的命名空间；

确定存储所转换的第一本体与多个本体的层级；

提取所转换的第一本体的基础；和

启用和存储所转换的第一本体的所提取的基础，以供基于所述基础的后续操作。

2.根据权利要求1所述的设备，其中，所述层级包括命名空间、本体和基础。

3.根据权利要求1所述的设备，其中提取所转换的第一本体的基础包括从相应的本体提取类和关系，以及提供所提取的类和与相应的类资源和关系资源的关系。

4.根据权利要求1所述的设备，操作进一步包括向显示设备提供指令以显示所转换的第一本体的所存储的基础。

5.根据权利要求1所述的设备，其中，所述对所转换的第一本体进行分类包括确定所转换的第一本体所属于的主题，其中所述主题与所转换的第一本体与之相关的关键字相关联。

6.根据权利要求1所述的设备，其中，所述对所转换的第一本体进行分类包括确定所转换的第一本体所属于的主题，其中所述主题与所转换的第一本体与之相关的关键字相关联，其中所述关键字与M2M垂直相关联。

7.根据权利要求1所述的设备，其中，所述对所转换的第一本体进行分类包括确定所转换的第一本体所属于的主题，其中所述主题与所转换的第一本体与之相关的关键字相关联，其中所述关键字与人的描述相关联。