一种智能家居语义网关的设计方法

摘要

一种智能家居语义网关的设计方法，涉及计算机数据传输和处理领域，基于Android平台，具体步骤为：第一、构建数据汇集系统，用于保存智能家居设备数据；第二、为存储智能家居设备的应用程序建立ContentProvider接口；第三、构建智能家居设备的语义本体；第四、为每个智能家居设备开发对应的语义数据转换接口；第五、启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。本发明能够使得智能家居网络开发人员方便高效地构建语义网关，降低开发难度，部署灵活，输出的智能家居语义数据能够由浏览器直观显示。

说明书

技术领域

本发明涉及计算机数据传输和处理领域，具体涉及一种智能家居语义网关的设计方法。

背景技术

智能家居(Smart Home)，是以住宅为平台，利用综合布线技术、网络通信技术、智能家 居-系统设计方案安全防范技术、音视频技术将家居生活有关的设施集成，构建高效的住宅设 施与家庭日程事务的管理系统，提升家居安全性、便利性、舒适性、艺术性，并实现环保节 能的居住环境。与普通家居相比，智能家居不但具有传统的居住功能，兼备建筑、网络通信、 管理为一体的高效、舒适、安全、便利、环保的居住环境，还提供全方位的信息交互功能。 智能家居概念的起源很早，但一直未有具体的建筑案例出现，直到1984年美国联合科技公司 将建筑设备信息化、整合化概念应用于美国康乃迪克州哈特佛市的CityPlaceBuilding时， 才出现了首栋的“智能型建筑”，从此揭开了全世界争相建造智能家居的序幕。

智能家居网关是智能家居系统的“大脑”，它不仅具有数据信息采集功能，而且还具有数 据分析处理的能力，实现了对家庭网络设备的智能化统一管理。但是，由于家居设备种类、 输出数据结构、信息传输模式和通信组网方式等千变万化、各不相同，系统所表现出的数据 格式、符号以及语法就存在着巨大差异，难以做到语义融合和基于统一语义的正确推理。大 量异构数据的理解、融合和互操作成为家居数据空间凸显的技术难题，这严重制约了智能家 居行业的发展。为此，我们在智能家居网关中引入了语义网技术来保证网络各节点语义一致 性。

传统的智能家居网关是一个基于关系数据库的简单应用，把智能家居网络中的各设备收 集的信息存到数据库中。用户在使用这些数据时需要清楚这些数据表达的语义。比如，某温 度传感器向网关报告当前温度值是25摄氏度，然而，用户在数据库中看到的只是25这个数， 并不是“当前温度值是25摄氏度”这个完整的语义。本发明要解决的就是在智能家居网关中 提供家居设备数据的完整语义描述，使用户不需要了解家居设备厂商对数据的定义细节，在 此基础上可以方便开发功能丰富的智能家居应用，实现类似于“若当前房间温度高于27摄氏 度，则启动空调制冷”这样的语义规则。这种语义网方法能够提高智能家居网络对网内各设 备采集的信息的分析和处理能力，是新一代互联网的一个发展方向。

吉林大学硕士生李程贵于2012年发表的学位论文“一种基于语义融合的智能家居系统的 研究与实现”，南京航空航天大学硕士生李辉于2012年发表的学位论文“基于MAS和OWL本 体的智能家居系统的研究”，这两篇文章都提出基于Jena的基于语义融合智能家居系统总体 设计方案，而Jena是由惠普实验室开发的语义网应用开发框架。该方案在语义推理上较成功， 但是缺少从非语义数据到有语义数据的直观转换方法。

北京邮电大学硕士生宋劼于2011年发表的学位论文“基于语义的智能家居管理系统关键 技术研究”，该文对智能家居环境中的场景进行分析，用语义推理的方法来描述场景规则，但 缺乏实现语义推理的实现框架及步骤，同时该文也缺少从非语义数据到有语义数据的直观转 换方法。

Yuwei Zhang、Zhiqiang Wei和Yongquan Yang发表于2012International Conference  on Computer Science and Service System(CSSS)会议上的论文“Ontology description of  smart home appl iance based on semantic web”(基于语义网的智能家居设备的本体描述)， 该文提出了基于语义网对智能家居设备建立本体，分别构建了三个本体：属性本体、状态本 体及服务本体。该方法可以实现异构数据的设备间进行信息的交换和数据的共享，但具有较 大的局限性，因为实际的智能家居设备产生的数据差异性较大，难以用少数几个本体完全描 述。另外，该文也缺少从非语义数据到有语义数据的直观转换方法。

发明内容

本发明的目的在于提供一种智能家居语义网关的设计方法，解决智能家居网络系统中缺 乏语义数据的问题。

本发明的具体方案是：

一种智能家居语义网关的设计方法，基于Android平台，具体步骤如下：

步骤1：构建数据汇集系统，用于保存智能家居设备数据；

步骤2：为存储智能家居设备的应用程序建立ContentProvider接口；

步骤3：构建智能家居设备的语义本体；

步骤4：为每个智能家居设备开发对应的语义数据转换接口；

步骤5：启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居 设备的有语义数据。

所述的Android平台为Android平板平台或者Android智能手机平台。

所述步骤1具体为在Android平台上创建保存智能家居设备数据的Sql ite数据库Hadb， 根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据，同 时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平台的数据库中。

所述步骤2还包括定义访问数据库的资源的路径，即通用资源标识URI。

所述步骤2中建立ContentProvider接口为：先定义ContentProvider类，使该类继承 Android提供的ContentProvider基类；再注册定义的ContentProvider类，在Manifest.xml 配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识 的URI。

所述步骤3具体为描述设备类型、对象属性、数据属性，生成对应的本体描述文件，即 是owl文件。

所述步骤4，为每个智能家居设备开发对应的语义数据转换接口是基于Android语义服务 框架进行开发的。

所述步骤4Android语义服务框架下，为每一种智能家居设备构建一个RDF Provider，RDF  Provider需要访问对应的Sql ite数据表，实现将智能家居设备数据暴露为RDF语义数据， 并自动地注册到RDF ContentResolver上。

所述RDF Provider为RDF TH Provider、RDF LightSensor Provider或RDF AirC Provider。

所述步骤5包括在智能家居语义网关上安装语义Web服务器RDF Server。

本发明的有益效果是：能够使得智能家居网络开发人员方便高效地构建语义网关，降低 开发难度，部署灵活，输出的智能家居语义数据能够由浏览器直观显示，由RDF语言表达的 形式化语义可以使机器真正的理解智能家居设备所采集到的数据的具体含义，从而为开发需 要语义融合、语义推理的更高级应用(如智能家居场景控制)提供基础。

附图说明

图1为基于语义网关的智能家居网络部署示意图(三个设备表示智能家居，从左到右分 别为空调、温湿度传感器和光照传感器)。

图2为本发明中智能家居语义网关的结构示意图。

图3为网关上的数据采集和存储中间件的流程图。

具体实施方式

本发明采用Android平板或Android智能手机作为实现智能家居网络语义网关的平台。 由于Android平台具有现成的Wifi，蓝牙无线能力，而智能家居设备组成的网络目前大多采 用Wifi或蓝牙，方便了智能家居网络的集成。并且，Android平台成本比专门开发的智能家 居网关成本要低得多，Android操作系统上丰富的软件资源降低了系统开发的难度。

具体设计步骤如下：

第一步、构建与传统无语义网关类似的数据汇集系统，即创建保存智能家居设备数据的 数据库，以及把智能家居网络中的各设备发给网关的数据进行解析并存入到数据库中的中间 件。这些数据是不含有语义的。需要通过下面的构建语义本体以及数据语义输出等步骤才能 得到有语义的智能家居设备数据。

第二步、为存储智能家居设备数据的Sql ite数据库所在的应用程序建立相应的 ContentProvider接口，供其他应用程序访问智能家居设备的数据。

第三步、构建智能家居设备的语义本体，描述设备类型、对象属性、数据属性，生成对 应的本体描述文件(.owl文件)。OWL文件是采用Web本体语言(Web Ontology Language，OWL) 刻画语义本体的文件。智能家居设备的本体描述文件刻画智能家居设备中涉及到的词汇以及 词汇之间的关系，是输出语义数据的基础。

第四步、在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开发对 应的语义数据转换接口。

第五步、启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家 居设备的有语义数据。

其中，第一步具体为在Android平台上创建保存智能家居设备数据的Sql ite数据库Hadb， 根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据，同 时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平台的数据库中。

第二步还包括还包括定义了访问数据库的资源的路径，即通用资源标识URI。具体为建 立ContentProvider接口为：先定义ContentProvider类，使该类继承Android提供的 ContentProvider基类；再注册定义的ContentProvider类，在Manifest.xml配置文件中注 册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识的URI。

第三步具体为描述设备类型、对象属性、数据属性，生成对应的本体描述文件，即是owl 文件。

第四步具体为在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开 发对应的语义数据转换接口。在Android语义服务框架下，为每一种智能家居设备构建一个 RDF Provider，RDF Provider需要访问对应的Sql ite数据表，实现将智能家居设备数据暴 露为RDF语义数据，并自动地注册到RDF ContentResolver上。

第五步还包括在智能家居语义网关上安装语义Web服务器RDF Server。

图1为基于语义网关的智能家居网络部署示意图。如图1所示，某智能家居网络部署中 包含三个智能家居设备和一个网关。三个智能家居设备分别是空调、温湿度传感器、光照传 感器，其中空调和温湿度传感器采用Wifi方式接入家居网络，光照传感器通过蓝牙方式接入 网络。网关是一个Android平板，运行Android操作系统，实现语义网关功能的组件如图2 所示，包括Sql ite数据库、数据采集中间件、设备语义数据转换接口、RDF解析接口以及语 义Web服务器。

下面就温湿度传感器、空调和光照传感器三种具体的智能家居设备设计语义网关的具体 实施例来详细说明。

实施例1：温湿度传感器。

步骤一：在Android平板上创建保存智能家居设备数据的Sql ite数据库Hadb。根据每 一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据。建立Sql ite 数据库表tempHum_data，其中含有7个字段，分别代表了每条数据的ID、温度值、温度单位、 湿度值、温度单位、采集数据的时间及温湿度传感器的开/关状态。

同时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平板的数据 库中。数据采集中间件运行流程图如图3所示。数据采集中间件是一个Android上开发的软 件，该软件是一个常驻服务进程，不断监听TCP/IP端口(假设是3467)或蓝牙通讯，获得智 能家居设备发来的数据包。例如，本实施例中的温湿度传感器发来以下格式的数据包： 0x7e0702010119064914。

包结构如下：

包头 包长 设备类型 包类型 设备ID 温度 湿度 1字节 1字节 1字节 1字节 1字节 2字节 2字节

数据采集中间件接收到数据包后，根据“包头”来判断一个包的起始字节，包头可以是 任何预先定义好的特殊符号，本例中采用0x7e作为包头。然后获取“包长”字段，不同的家 居设备上报的数据是不一样的，导致数据包长度是不固定的，“包长”字段确定数据包中后续 字节的长度，本例中的包长为0x07，是不包含包头和包长字段的后续数据的字节个数。数据 采集中间件根据包中的“设备类型”字段区分设备是哪一种，如本例中根据设备类型0x02判 断当前设备类型为温湿度传感器。同一设备如果数据很多，可根据功能划分为不同的包，并 用不同的包类型值来区分。后续的字段是设备ID，是用来区分在一个网络中部署的多个同一 种类的设备，本例中温湿度传感器的设备ID为0x01。之后是温度字段和湿度字段，都是用 两个字节表示的，第一个字节表示十进制中小数点前的整数，第二个字节表示十进制中小数 点后的2位整数，本例中，0x1906表示当前温度值为25.6度，0x4914表示当前湿度值为 73.20RH。数据采集中间件把上述数据包进行分析后在数据库表tempHum_data插入一条新的 记录，各字段赋值如下：数据ID自动加1、温度值为25.6、温度单位degC、湿度值73.2、 温度单位RH、采集数据的时间近似地取网关当前时间，温湿度传感器的开/关状态为On。

步骤二：为存储智能家居设备的应用程序建立ContentProvider接口。上述第一步建立 的数据库只是本地数据库，并不能让远端程序访问。本步骤的目的是提供其他应用程序访问 数据库的接口，同时定义访问数据库的资源的路径-通用资源标识(URI)。

其他应用程序访问数据库中的数据并不是直接访问ContentProvider，而是通过 ContentResolver来操作ContentProvider所暴露的数据。Android的ContentProvider，具 有query(查询)、insert(插入)、update(更新)、delete(删除)操作(CRUD方法)，对应于具 体的数据库操作。ContentResolver操作ContentProvider是通过URI实现的，通过URI参 数找到该URI对应的ContentProvider,再由该ContentProvider来负责实现CRUD方法，从 而实现对存储在SQLite数据库中的数据进行query、insert、update、delete操作。

Android的ContentProvider，具有query(查询)、insert(插入)、update(更新)、 delete(删除)操作。对于ContentResolver来说，它是用来操作ContentProvider的，也就 是说它应该操作ContentProvider的CURD四个方法，所以它也具有四个方法。

通过上面的四个方法我们可以看出来对于ContentProvider和ContentResolver的CRUD 四个方法中的第一个参数是通用资源标志URI，URI是两者进行数据交换的标识。 ContentResolver执行CRUD操作时会通过URI参数找到该URI对应的ContentProvider，从 而使得对应的ContentProvider来负责实现CRUD方法，从而实现对存储在SQLite数据库中 的数据进行query、insert、update、delete操作。URI主要包含了两部分信息：1)、需要 操作的ContentProvider，2)、对ContentProvider中的什么数据进行操作。一个URI由以 下3部分组成：scheme+Authority+path，其中：scheme已经由Android规定为：content://； Authority用于唯一标识这个ContentProvider，外部调用者可以根据这个标识来找到它。 path用来表示我们要操作的数据，路径的构建应根据用户所访问的数据来定。如我们要访问 SQLite数据表temphum_data的所有数据项，我们就可以将路径设置为/temphum_data；如果 我们需要访问Sql ite数据表temphum_data的ID为35的数据项，那么我们将路径设置为 /temperature_data/35。

构建一个ContentProvider只需要两步：1、定义自己的ContentProvider类，使得该类 继承Android提供的ContentProvider基类。2、注册所定义的ContentProvider类，在 Manifest.xml配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定 一个唯一标识的URI。

定义温湿度传感器的ContentProvider为TemProvider，首先定义TemProvider的工具 类Temps,该工具类主要包含一个publ ic static的常量，这个常量类中包含了该 ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该 ContentProvider的Authority为"com.zxl.homeautoprovider.temps"，同时定义Content 所允许操作的7个数据列_ID，TEMPERATUREVALUE，TEMPERATUREUNIT，HUMIDITYVALUE， HUMIDITYUNIT，TIME，STATUS，定义该Content提供服务的两个URI："content://"+AUTHORITY +"/temp_data"，以及"content://"+AUTHORITY+"/temp_data/#"然后使用URIMatcher工具 类为TemProvider注册URI,实现过程如下：1)、构造一个URIMatcher实例，matcher＝new  URIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量表示不匹配任何路径的 返回码。2)、为URIMatcher注册两个URI：1个是matcher.addURI(Temps.AUTHORITY， "temp_data"，TEMPS)，另一个为matcher.addURI(Temps.AUTHORITY,"temp_data/#",TEMP)。 如果通过match(URI)方法匹配了content://com.zxl.homeautoprovider.temps/temp_data， 就会返回匹配码为TEMPS，表示多个数据记录；如果通过该match(URI)方法匹配了 content://com.zxl.homeautoprovider.temps/temp_data/#，那么返回的返回码为TEMP，表 示某一个数据记录。

步骤三：构建智能家居设备的语义本体，描述设备类型、对象属性、数据属性，生成对 应的本体描述文件(.owl文件)。1、通过对本体构建的需求分析，确定“温湿度传感器”这 一本体对象覆盖的所研究领域范围为智能家居设备领域；2、列出“温湿度传感器”中涉及到 的相关的重要的词语，并确定这些词语相互间的关系和属性。由于温湿度传感器的功能只有 分别测试温度、湿度，温湿度传感器是智能家居设备抽象类的子类，并且温湿度传感器具有 开关状态(开启/关闭)、参数(温度、湿度)的属性并且每个参数都具有自己的值和对应的 单位。通过分析可知该本体对象所涉及到比较重要的词汇为home automation devices、 temperature and humidity sensors、status、parameters、unit、value。3、确定描述这 些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系，本例中主要有 三种关系，has status(定义域为temperature and humidity sensors，值域为status)、 has unit(定义域为parameter，值域为unit)、has value(定义域为parameter，值域为 value)。数据属性是类的实例包含哪些的数据，本例中的数据属性有degree C(定义域为unit， 数据类型为boolean)、RH(定义域为unit，数据类型为boolean)、temperature value(定 义域value，数据类型为float)、humidity value(定义域value，数据类型为float)、 status(定义域为status,值域为boolean)。利用语义本体工具软件protege分别配置表示两 个类的实例间关系的object property和表示类实例的属性值的data property，生成用 RDF/XML语言描述的owl文件即本体文件。完整的本体描述文件放置在网关语义程序目录中， 供语义转换接口组件使用。

步骤四：在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开发对 应的语义数据转换接口。Android语义服务框架，是指法国Inria研究中心开发的一组用于 在Android移动设备上开发语义应用的软件包，包括RDFServer，RDFProvider，RDFBrowser， RDFContentResolver，其中，RDFProvider是用户需要针对具体设备开发的语义数据转换接 口，允许应用程序将自己的数据暴露为RDF语义数据；RDFContentResolver是图2中的RDF 解析接口，它是访问语义数据的统一接口，RDFServer是语义Web服务器，为网络上的其它 计算机提供访问RDFContentResolver的能力，RDFBrowser是在网关本机上运行的语义浏览 器，直接访问RDFContentResolver。

在本发明的语义网关中需为每一种智能家居设备构建一个RDF*Provider(*分别为TH， LightSensor，AirC)，RDF*Provider最终需要访问对应的Sql ite数据表。RDF*Provider实 现了将智能家居设备数据暴露为RDF语义数据。RDF*Provider实例化后就会自动的注册到 RDFContentResolver上，RDFContentResolver继承自Android Service，其工作过程是在后 台运行的对用户而言是不可见的。

具体工作过程如下：RDFContentResolver上安装了被实例化的RDF*Provider，当 RDFBrowser地址栏中输入了需要查看的智能家居设备数据的URI。温湿度传感器的第1条记 录，其URI为content://com.zxl.homeautoprovider.temps/temp_data/1)，此时RDFBrowser 检索到该URI并且发送给RDFContentResolver，RDFContentResolver根据该URI再查询安装 在其上的URI所对应的RDFTHProvider，该provider接收到返回该条记录的语义数据的请求 后，就会返回包含7组statement(由于该数据表中除了_id字段后有7列数据)的Rdf Cursor 对象，RDFContentResolver进而通过Jena接口构建RDF模型，并将7组statement的<subject， predicate，object>三元组数据解析出来并添加在所构建的RDF模型对象里，最后通过写RDF， 将该模型对象的数据封装成文件并且通过RDFBrowser的用户界面返回给用户。

RDFTHProvider主要是通过get(URI URI)方法实现了将TemProvider的数据暴露为语义 数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。RDFContentResolver 及RDFBrowser都是通过调用get()方法来获取包含多个RDF Statement对象的Rdf Curosr 对象，即三元组<subject，predicate，object>对象，其中subject为当前数据id所对应的 URI的字符串，predicate为数据表中字段在本体文件中的URI所对应的字符串，object为 数据表中字段所对应的值。实现get()方法前，在RDFTHProvider首先要定义两个对象，它 们分别是，1)、定义用于映射存储智能家居设备数据的数据表各个字段(如温湿度传感器的 数据表temp_data)与temperature.owl本体文件中各个data property的URI关系的哈希 表对象TEMP_PROPS，该对象的键为数据表的各个字段，值为温湿度传感器本体中所对应的 data property的URI。2)、定义RDFTHProvider所对应的原始TemProvider的 URI(content://com.zxl.homeautoprovider.temps/temp_data)为baseURI。该baseURI实际 上就是我们需要访问的数据库表中原始无语义数据所对应的URI,也是需要我们进行语义注释 的对象。

在RDFBrowser搜索温湿度传感器数据库表中的第一条记录的URI中，首先get()方法通 过输入的URI对象content://com.zxl.homeautoprovider.temps/temp_data/。1)、用 ContentResolver实例对象cr来调用该URI所对应的TemperatureProvider的query()方法， 并且获取了包含该条记录Cursor对象。2)、Cursor对象是每一行的集合，使用moveToFirst 方法来定位第一行，并通过getColumnCount()获取该条记录所有列数，共有8列(含有_id字 段)。3)、根据TEMPERATURE_PROPS所含列数定义了1个含有7个元素的int型数组 idx(idx[0]-idx[6]分别对应temperature_data表中的7个字段所对应的值分别为{22.6， degreeC，68.3，RH，2014-9-1811：46：34，1，0})，判断哈希表对象TEMP_PROPS的列数 与temp_data数据表中的列数是否相同，若相同就直接获取_id所在的列索引idIdx，根据判 断可知idIdx为1，根据cursor.getInt(idIdx)方法获取当前记录的id值为1。4)、根据 cursor.getString(idx[0])方法获取了该列名temperatureValue所对应的值为22.6。5)、 并通过TEMP_PROPS.get(cursor.getColumnName(idx[0])).toString()方法获得 temperatureValue键所对应的值http://localhost/temperature.owl#temperatureValue的 字符串形式，该值即为本体中关于temperatureValue该dataproperty的URI所对应的字符 串。6)、创建一个Statement对象stmt，a)该对象的Resource对象subject为baseURI+当 前记录的id值即为content://com.zxl.homeautoprovider.temps/temp_data/1的字符串形 式；b)该对象的Property对象predicate为5)中所获取的字符串 “http://localhost/temperature.owl#temperatureValue”；c)该Statement对象的Object 对象object为4)中所获得的值22.6。7)、通过hasNext()方法检测到还有下一列时，通过 循环的方法再次构建6个Statement对象，并且6个对象的subject值都 为”content://com.zxl.homeautoprovider.temps/temp_data/1”，predicate值为 TEMPERATURE_PROPS其他各个键所对应的值的字符串形式，object值分别为temp_data数据 表中各个字段所对应的值。至此7组RDF Statement对象都存储在了Rdf Cursor中了，从 而实现了温湿度传感器第一条记录的语义注释。

步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智 能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务 器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏 览器通过访问语义网关获取有语义的智能家居设备数据。在温湿度传感器语义网关设计中， 假设网关IP地址为10.17.52.71，网关语义Web服务器RDFServer使用缺省端口号8080，打 开Web，输入http://10.17.52.71:8080/com.zxl.homeautoprovider.temps/temp_data/1， 若是输入http://10.17.52.71:8080/com.zxl.homeautoprovider.temps/temp_data/1，该 URI来访问RDFserver时，RDFServer首先会接受外部请求并将外部的URI转换为内部可识别 的URI content://com.zxl.homeautoprovider.temps/temp_data/1,接下来RDFServer将装 换后的URI传递给RDFContentResolver，RDFContentResolver又根据该URI查找到了与之相 对应的RDFContentProvider即RDFTemperatureAndHumiditySensorsProvider并调用该 provider中的get()方法，从而获取包含7组RDF Statments对象的Rdf Cursor对象，进而 对该Rdf Cursor通过Jena接口实现RDF解析，最终将解析后的语义数据结果以RDF文件的 形式返回给了用户。

实施例2：空调。

步骤一：在Sql ite数据库HAdb中为空调设备建立Sql ite数据库表aircon_data，其中 含有10个字段，分别代表了每条数据的ID、当前温度、目标温度、当前时间、目标时间、 状态开、状态关、运行模式、风扇速度、定时模式。数据采集中间件获取空调通过Wifi传来 的原始数据，按字段解析，生成新记录，插入aircon_data表中。

步骤二：为空调构建一个可供其他应用程序访问其数据的AirconditoningProvider接 口，该接口继承了Android Content Provider。具体构建过程如下：首先定义AirConProvider 的工具类AirCons，该工具类主要包含一个publ ic static的常量，这个常量类中包含了该 ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该 ContentProvider的Authority为"com.zxl.homeautoprovider.aircons"，同时定义Content 所允许操作的10个数据列_id，currentSetTemp，targetSetTemp，currentTime，targetTime， statusOn，statusOff，operationMode，fanSpeed，timerMode。定义两个URI："content://" +AUTHORITY+"/aircon_data"以及"content://"+AUTHORITY+"/aircon_data/#"，然后使用 URIMatcher工具类为AirConProvider注册注册URI，实现过程如下：1)、构造一个URIMatcher 实例matcher＝new URIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量 表示不匹配任何路径的返回码。2)、为URIMatcher注册两个URI： matcher.addURI(AirCons.AUTHORITY，"aircon_data"，AIRCONS)对应多条空调数据记录和 matcher.addURI(AirCons.AUTHORITY，"aircon_data/#"，AIRCON)对应单条空调数据记录。

步骤三：构建空调的本体，其过程如下。通过对本体构建的需求分析，确定“空调”这 一本体对象覆盖的所研究领域范围为智能家居设备领域；列出“空调”中涉及到的相关的重 要的词语，并确定这些词语相互间的关系和属性。由于空调可实现显示当前温度、设定目标 温度，选择风速，选择当前的工作模式及定时等功能，且空调是智能家居设备抽象类的子类， 并且空调具有开关状态(开启/关闭)。通过分析可知该本体对象所涉及到比较重要的词汇为 home automation devices、air conditioning、status、parameters、unit。

确定描述这些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系， 本例中主要有三种关系，has status(定义域为air conditioning，值域为status)、has unit (定义域为parameter，值域为unit)、has parameter(定义域为air conditioning，值域 为parameter)。数据属性是类的实例包含哪些的数据，本例中的数据属性有current set  temperature(定义域为temperature，数据类型为float)、target set temperature(定义域 为temperature，数据类型为float)、fan speed(定义域air conditioning，数据类型为 l iteral)、operate mode(定义域air conditioning，数据类型为l iteral)、timer mode(定 义域为air conditioning,值域为l iteral)、status on(定义域air conditioning，数据 类型为boolean)、status off(定义域air conditioning，数据类型为boolean)。利用语 义本体工具软件protege分别配置表示两个类的实例间关系的object property和表示类实 例的属性值的data property，生成用RDF/XML语言描述的owl文件即本体文件。完整的本 体描述文件放置在网关语义程序目录中，供语义转换接口组件使用。

步骤四：构建可将空调数据暴露为供其他应用程序访问的RDF语义数据的 RDFAirCProvider接口。该接口类主要是通过get(URI URI)方法实现了将AirConProvider的 数据暴露为语义数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。 RDFContentResolver及RDFBrowser都是通过调用get()方法来获取包含多个RDF Statement 三元组<subject，predicate，object>对象的Rdf Curosr对象。其中三元组中的subject为 当前数据id所对应的URI的字符串，predicate为数据表中字段在本体文件中的URI所对应 的字符串，object为数据表中字段所对应的值。

实现get()方法前，在RDFAirCProvider首先要定义两个对象，它们分别是1)、定义1 个用于映射存储智能家居设备数据的数据表各个字段与air_conditioning.owl本体文件中 各个data property的URI关系的哈希表对象AIRCON_PROPS，该对象的键为数据表的各个字 段，值为空调本体中所对应的data property的URI。2)、定义RDFAirCProvider所对应的 原始AirConProvider的URI(content://com.zxl.homeautoprovider.aircons/aircon_data) 为baseURI。该baseURI实际上就是我们需要访问的数据库表中原始无语义数据所对应的URI， 也是需要我们进行语义注释的对象。

步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智 能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务 器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏 览器通过访问语义网关获取有语义的智能家居设备数据。

实施例3：光照传感器。

步骤一：在Sql ite数据库HAdb中为空调设备建立Sql ite数据库表l ight_data，其中 含有6个字段，分别代表了每条数据的ID、当前光照强度值、当前光照强度单位、当前时间、 状态开、状态关。数据采集中间件获取光照传感器通过蓝牙无线传来的原始数据，按字段解 析，生成新记录，插入l ight_data表中。

步骤二：为光照传感器构建一个可供其他应用程序访问其数据的LightProvider接口， 该接口继承了Android Content Provider。具体构建过程如下：首先定义LightProvider的 工具类Lights，该工具类主要包含一个publ ic static的常量，这个常量类中包含了该 ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该 ContentProvider的Authority为"com.zxl.homeautoprovider.l ights"，同时定义Content 所允许操作的6个数据列_id，l ightIntensityValue，l ightIntensityUnit，currentTime， statusOn，statusOff。定义两个URI："content://"+AUTHORITY+"/l ight_data"以及 "content://"+AUTHORITY+"/l ight_data/#"，然后使用URIMatcher工具类为AirConProvider 注册注册URI，实现过程如下：1)、构造一个URIMatcher实例matcher＝new  URIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量表示不匹配任何路径的 返回码。2)、为URIMatcher注册两个URI：matcher.addURI(Lights.AUTHORITY， "l ight_data"，LIGHTS)对应多条光照传感器数据记录和 matcher.addURI(Lights.AUTHORITY，"l ight_data/#"，LIGHT)对应单条光照传感器数据记 录。

步骤三：构建光照传感器的本体，其过程如下。通过对本体构建的需求分析，确定“光 照传感器”这一本体对象覆盖的所研究领域范围为智能家居设备领域；列出“光照传感器” 中涉及到的相关的重要的词语，并确定这些词语相互间的关系和属性。由于光照传感器只有 实现显示当前光照强度功能，且光照传感器是智能家居设备抽象类的子类，并且具有开关状 态(开启/关闭)。通过分析可知该本体对象所涉及到比较重要的词汇为home automation  devices、l ight sensor、status、parameters、l ight intensity、unit、value。确定描 述这些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系，本例中主 要有四种关系，has status(定义域为l ight sensor，值域为status)、has unit(定义域 为l ight intensity，值域为unit)、has parameter(定义域为l ight sensor，值域为 parameter)、has value(定义域为l ight intensity，值域为value)且has unit和has value 都是has parameter的子属性。数据属性是类的实例包含哪些的数据，本例中的数据属性有 l ight intensity value(定义域为value，数据类型为float)、tl ight intensity unit(定 义域为unit，数据类型为l iteral)、status on(定义域l ight sensor，数据类型为boolean)、 status off(定义域l ight sensor，数据类型为boolean)。利用语义本体工具软件protege 分别配置表示两个类的实例间关系的object property和表示类实例的属性值的data  property，生成用RDF/XML语言描述的owl文件即本体文件l ight_sensor.owl。完整的本体 描述文件放置在网关语义程序目录中，供语义转换接口组件使用。

步骤四：构建可将光照传感器数据暴露为供其他应用程序访问的RDF语义数据的 RDFLightProvider接口。该接口类主要是通过get(URI URI)方法实现了将LightProvider的 数据暴露为语义数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。 RDFContentResolver及RDFBrowser都是通过调用get()方法来获取包含多个RDF Statement 三元组<subject，predicate，object>对象的Rdf Curosr对象。其中三元组中的subject为 当前数据id所对应的URI的字符串，predicate为数据表中字段在本体文件中的URI所对应 的字符串，object为数据表中字段所对应的值。

实现get()方法前，在RDFLightProvider首先要定义两个对象，它们分别是1)、定义1 个用于映射存储智能家居设备数据的数据表各个字段与l ight_sensor.owl本体文件中各个 data property的URI关系的哈希表对象LIGHT_PROPS，该对象的键为数据表的各个字段， 值为光照传感器本体中所对应的data property的URI。2)、定义RDFLightProvider所对应 的原始LightProvider的URI(content://com.zxl.homeautoprovider.l ights/l ight_data) 为baseURI。该baseURI实际上就是我们需要访问的数据库表中原始无语义数据所对应的URI， 也是需要我们进行语义注释的对象。

步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智 能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务 器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏 览器通过访问语义网关获取有语义的光照传感器数据。