基于移动终端的语义桌面搜索系统的设计与实现 精灵论文

基于移动终端的语义桌面搜索系统的与实现 精灵论文 基于移动终端的语义桌面搜索系统的设计 与实现 王冠 (北京邮电大学网络与交换技术国家重点实验室，北京 100876) 摘要:随着移 动智能终端上用户个人数据的不断增长和日益丰富，以及语义桌面技术的快速 发展，将移动 终端上的用户个人数据进行语义存储并提供给用户基于语义的桌面搜索方式， 显得十分有 意义。本文介绍了一个基于 N900 移动智能终端的语义桌面搜索系统的设计与实 现，系统能 够帮助用户在移动终端上方便地以关键词搜索的方式实现对电子邮件、短信、日 程表、联系 人等个人信息进行基于本体的语义搜索，从而帮助用户更快速便捷地找到自己需 要的信息。 关键词:移动终端;语义桌面;关键词查询;语义搜索;语义查询构造 中图分类号:TP311 Design and Implementation of Semantic Desktop Search System on Moblie Phone WANG Guan (State Key Lab of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876) Abstract: In nowadays, personal information and data on smart mobile phone increase and get richer more and more rapidly. And with the rapid development of semantic desktop technology, to store the personal data on mobile phone into the semantic storage and provide a semantic search method to the users becomes more and more important. In this paper, we introduce the design and implementation of a semantic desktop search system on N900 smart mobile phone, which aims to enable users searching semantic information about Email, SMS, Calendar, Contact data. Users could use simple keyword query to launch a semantic search and thus be able to find their real information needs conveniently and efficiently. Key words: Moblie Phone; Semantic Desktop; Keyword Query; Semantic Search; Semantic Query Construction 0 引言 在信息社会中，随着个人用户数据的不断增长，语义桌面技术的重要性越来越突出。语 义桌面是一个满足个人存储文档、多媒体、消息等数字化信息的设备，这些信息作为语义网 资源来描述，用 URI 进行标注，并可通过 RDF 图存储和检索;同时，语义桌面是对用户内 存的扩大补充:通过使用本体，使得用户可以表达个人心智模型和实现信息与系统的互连; [1]应用程序使用本体和语义网的，实现信息存储、访问和通讯。 另外，由于移动智能终端的日益普及和计算能力的日益强大，移动智能终端在人们的生 活中扮演着越来越重要的角色，并有逐步取代个人计算机的趋势。人们经常使用的移动终端 上的短信、电子邮件、日程表、地址薄等功能，包含着大量丰富的用户桌面数据和个人信息。 因此，把移动终端打造成一个语义桌面，对用户常用的数据进行语义存储并提供给用户基于 语义的搜索方式，显得十分有意义。另外，由于大部分终端用户在进行桌面搜索时已经习惯 于基于关键词的搜索方式，如何将关键词搜索和语义搜索结合起来也是一个挑战。本文介绍 作者简介:王冠(1986-)，男，硕士研究生，主要研究方向:移动终端应用. E-mail: wang_guan13579@163.com 了一个基于诺基亚 N900 移动智能终端的语义桌面搜索系统的设计与实现，目的在于帮助用 户在移动终端上方便地进行电子邮件、短信、日程表、地址薄等信息的语义搜索，并能够方 便地使用关键词搜索实现基于本体的语义搜索，帮助用户更方便地找到自己需要的信息。 1 系统总体架构 本系统在基于 Maemo5 平台的 N900 移动智能终端上实现用户数据的语义桌面搜索。系 统主要分为数据提取(Data Extraction)模块，语义数据存储(Semantic Data Indexing)模块， 语义查询构造及查询(Semantic Query Construction and Search)模块，以及用户接口(User Interface)模块。系统总体架构如图 1 所示。 User Interface Search Result Keyword Query Show Semantic Query Construction and Search Keywords Formal Query Query Semantic Mapping Construction Ranking Search Semantic Data Indexing Tracker Content Metadata Lucene Index Storage Indexing Store Data Extraction Email Calendar Contact SMS Extraction Extraction Extraction Extraction 图 1 系统架构图 Fig. 1 The Architecture of The System 2 数据提取模块 数据提取模块负责 N900 移动终端上的邮件、短信、日历、联系人等数据的提取，为索 引和搜索模块提供原始的数据源。 2.1 邮件内容提取 在 Maemo5 平台中，Email 系统采用的是 Modest Email 客户端。Modest 由诺基亚 Maemo 项目开发，是一个免费、开源的 Email 客户端，支持常用的 Email 协议如 IMAP、POP、SMTP 等它基于轻量级的 Tinymail Email 框架，因而只占用少量的系统资源，适合应用于软硬件资 源都比较有限的移动终端上。Modest 的架构如图 2 所示。 图 2 Modest 架构如图 Fig. 2 The Architecture of The Modest Modest 提供开放的 API 接口 libmodest-dbus-client，支持 Email 的打开、发送与接收， 以及内容查找等操作。邮件内容提取功能需要提取 N900 终端上所有 Email 的相关信息，即 使用 libmodest-dbus-client API 提取所有 Email 的 uri、subject、sender、timestamp 等信息， 同时由于 API 不支持 Email 的 recipient、body 的提取，因此需要从存储 Email 的文件系统中 通过扫描文件的方式来提取相应 Email 的 recipient、body 等信息。 2.2 短信内容提取 Maemo5 平台中采用 Eventlogger 作为通信事件记录框架(communications event logging framework)。Eventlogger 用来记录聊天(Chats)、电话(Calls)、以及短消息(SMS)等 通信事件。它基于 GObject 对象实现，使用 SQLite 数据库进行存储，并且采用 DBus 对多个 并发使用它的应用程序进行同步。 Eventlogger 开放的 API 是 rtcom-eventlogger 库，它可以处理相关的数据库访问操作并 logger 框架下的通信事件(Event)进行插入、修改、查询等 提供了高层的 API 用来对 Event 操作。每个 Event 关联到一个 Event Type(如 inbound/outbound message、voicemail、missed call 等)，并且属于一个特定的 Service(如 chat、call、sms 等)，另外 Event 也可以有一些 flags(如 sms event 的 pending sms flag 等)。rtcom-eventlogger 的数据库模式如图 3 所示。 图 3 rtcom-eventlogger 的数据库模式 Fig. 3 The Database Schema of rtcom-eventlogger 短信内容提取功能需要使用 rtcom-eventlogger API 来提取所有 SMS 的 id、timestamp、 sender、recipient、free_text 等信息。 2.3 日历内容提取 Maemo5 平台中采用了开源的 Evolution Data Server 作为日历和联系人功能的框架。 Evolution Data Server(EDS)为 Evolution 应用以及其它应用程序提供了对日历(Calendar)、 任务(Tasks)以及地址薄(Addressbook)等信息的访问。EDS 是一个 CORBA 组件，支持 多个客户端应用程序对同一数据的并发访问，处理数据变化的情况，并通过信号将数据的变 [2]化告知所有客户端。EDS 具有可扩展的架构，支持各种外部插件以共享库的方式提供，并 在 evolution-data-server 启动时加载，来处理不同的日历、任务、地址薄的数据源。Evolution Data Server 中 Calendar 的架构如图 4 所示。 图 4 Evolution Data Server 中 Calendar 的架构 Fig. 4 The Calendar Architecture in Evolution Data Server Maemo5 平台提供的访问日历数据源的 API 是 calendar-backend，它用来处理对 Maemo5 平台上 EDS 的后端日历数据的访问。calendar-backend 中主要的类包括 CCalendar(增加、 修改、删除 Calendar 以及 Calendar 中的 Component 如 Event、Todo、Journal、Birthday 等)， CCalendarDB(与 SQLite 数据库交互)，以及 CComponen(t 存取 Component 如 Events、Todo、 Notes 的基本信息)等。 日历内容提取功能需要使用 calendar-backend API 来提取所有日历项的 id、type、 summary、description、location、start_time、end_time、create_time、modify_time 等信息。 2.4 联系人内容提取 Evolution Data Server(EDS)提供了地址薄(Addressbook)的功能，用来存取联系人 (Contact)的信息。EDS 支持多个后端从多个数据源中存取 Contact 信息。通常，EDS 使用 基于文件的后端，即按照 vCard 将 Contact 信息存储在本地数据库中。另外，在 Maemo5 中也增加了基于 SIM 卡和基于 Telepathy 的后端，以支持访问存储在 SIM 卡上和聊天花名册 (Chat rosters)上的 Contact 信息。Maemo5 中 Addressbook 栈的架构如图 5 所示。 高层的 libosso-abook 库将 EDS 所有的后端抽象成了一个简单、一致的 Contact 存储， 较底层的 libebook 库提供了对存储在 EDS 中的 Contact 的访问。libosso-abook 库在内部广泛 使用了 libebook 库的功能，简化了对 libebook 的访问，并支持高级的 Contact 聚合 (Aggregation)、表示抽象等功能。但对于稍复杂的 Contact 操作，尤其是 Contact 详细信 息的提取，libebook 库提供的功能却更加丰富。联系人内容提取功能需要使用 libebook API 来提取所有 Contact 的 contact_book_uri、full_name、nickname、phone_list、email_list、gtalk_list、 address_home、birthday、home_page、job_title、company、note 等信息。 图 5 Maemo5 中 Addressbook 栈的架构 Fig. 5 The Addressbook Stack in Maemo5 3 语义数据存储模块 从 N900 移动终端上提取出所有 Email、SMS、Calendar、Contact 的信息后，就要对这 义数据存储模块负责将提取出的信息组织起来，将信息所包含的语义进 些数据进行存储。语 行有效的存储和索引，以支持语义查询模块进行准确高效的语义查询。 在语义数据存储模块中，提取出的 Email、SMS、Calendar、Contact 等信息作为语义数 据，将以本体的形式存储起来。系统中使用 Tracker 作为语义数据的存储和搜索引擎，针对 Email、SMS、Calendar、Contact 等几种信息类型，分别采用 NEPOMUK 消息本体 (NEPOMUK Message Ontology)、NEPOMUK 日历本体(NEPOMUK Calendar Ontology)、 NEPOMUK 联系人本体(NEPOMUK Contact Ontology)三种本体分别来存储 Email、SMS、 Calendar、Contact 的信息。三种本体的介绍如下。 3.1 NEPOMUK Message Ontology(NMO) NEPOMUK 消息本体(NMO)在消息(Message)领域扩展了 NIE 框架。消息在用户 桌面数据中占有很大的比重，用户日常发送，接收，转发，存储消息，并在需要的时候回想 起这些消息。消息通常都不是独立存在的，它们总是涉及到其他的信息，比如某件事、某个 人、某个组织、某个项目、某个活动等等，总之有可能关联到用户感兴趣的任何事物。NMO 的目的在于将消息引入本体的世界，以便这些事物之间的关联可以被明确地定义。NMO 消 息的子概念包括了 Email、SMS、即时通信消息、语音信息、论坛私信等。每个消息最重要 [3]的信息是发送者、接收者以及日期。NMO 提供了各种属性来表示这些信息。 语义数据存储模块中主要用到的 NMO 的类有 nmo:Message，nmo:Email。主要用到的 NMO 的属性有 nmo:from，nmo:to，nmo:primaryRecipient，nmo:receivedDate 和 nmo: messageSubject。 存储 Email 语义数据时，为每个 Email 创建一个 nmo:Email 类的实例，将 Email 的元数 据存储在 nmo:Email 的各种属性中。存储 SMS 语义数据时，为每个 SMS 创建一个 nmo: Message 类的实例，将 SMS 的元数据存储在 nmo: Message 的各种属性中。 3.2 NEPOMUK Calendar Ontology(NCAL) NEPOMUK 日历本体(NCAL)用来描述各种日历项(Calendar entry)如事件(Events)、 任务(Tasks)、日志(Journal)等，这些数据是日常存储在桌面的数据中很重要的一部分。 NCAL 符合著名的 RFC2445 iCalendar 标准，并对由语义网兴趣组(Semantic Web Interest Group)的 W3C RDF 日历工作组(RDF Calendar Task Force)创建的 ICALTZD 本体进行了 [4]修正和改编，解决了 ICALTZD 存在的一些缺陷，并使之符合 NIE 框架。 语义数据存储模块中主要用到的 NCAL 的类有 ncal:Event，ncal:Todo，ncal: Journal。主 要用到的 NCAL 的属性有 ncal:summary，ncal:description，ncal:location，ncal:dtstart，ncal:dtend， ncal:created，ncal:lastModified。 存储 Calendar 语义数据时，根据 Calendar Component 的类型(Event/Todo/Journal)，为 每个 Calendar Component 创建一个 ncal: Event/ncal: Todo /ncal: Journal 类的实例，将 Calendar Component 的元数据存储在相应类的各种属性中。 3.3 NEPOMUK Contact Ontology(NCO) NEPOMUK 联系人本体(NCO)用来描述普遍存在于桌面上的联系人(Contact)信息。 NCO 中 Contact 的含义比较广，它代表了能够标识一个实体的数据或者能与之进行通信的方 [5]法。NCO 的定义包含了两个方面:标识和通信。 语义数据存储模块中主要用到的 NCO 的类是 nco:Contact。主要用到的 NCO 的属性有 nco:fullname，nco:nickname，nco:hasPhoneNumber，nco:hasEmailAddress，nco:hasIMAccount， nco:hasPostalAddress，nco:hasAffiliation，nco:title，nco:birthDate，nco:url，nco:note。 存储 Contact 语义数据时，为每个 Contact 创建一个 nco: Contact 类的实例，将 Contact 的元数据存储在 nco: Contact 的各种属性中。 语义数据存储功能使用 Tracker 作为语义数据的存储引擎。Tracker 中查询和更新语义数 据的 API 是 libtracker-sparql 库，它支持使用 SPARQL 对基于 NEPOMUK 本体的语义数据 进行查询和插入。语义数据存储主要使用 libtracker-sparql 的数据插入功能。主要步骤为: 1)创建 TrackerSparqlConnection 连接。 2)分别构造插入 Email、SMS、Calender、Contact 语义数据的 SPARQL query。 3)调用 tracker_sparql_connection_update 接口，执行插入数据的 query，完成 Email、SMS、 Calender、Contact 语义数据的存储。 插入语义数据时主要 使用 SPARQL 的 INSERT 语句。 4 语义查询自动构造及查询模块 在进行桌面搜索时，关键字查询为用户提供了便捷的方式来表达自己的信息需求，而基 于本体的语义查询由于带有明确的语义信息，能产生更加精确的查询结果。因此，如何能将 这两种搜索方式结合起来，帮助用户高效地找到自己需要的信息，是一个挑战。为此，我们 提出了一种将用户的关键字查询自动构造为 SPARQL 语义查询的方法。 大量研究表明，大部分用户已经十分习惯于传统的关键字查询，通过输入几个简单的关键词，来表达自己的信息需求。虽然信息检索领域(IR)中的关键字查询不能表达用户查询 [6]的精确含义，但它可以提供基于统计的最匹配的查询结果。而另一方面，对于用户桌面上 可以用本体来形式化描述的知识领域，语义查询可以通过明确的语义信息，来精确地表达用 户的查询意图，从而得到更加准确的查询结果。 然而，普通的用户通常并不熟悉领域相关的语义本体，也不了解类似 SQL 的形式化查 [7]询语言。为了进行语义查询，用户需要掌握复杂的形式化查询语言，并且要对本体知识库 有所了解。因此，让用户通过输入关键字就能进行语义查询就显得十分有必要。然而，根据 [8]所述，将关键字查询转化为语义查询，存在着诸多困难:1)词汇差距:用户通常并不知 道本体知识库的存在，因此用户在关键字查询时使用的词汇与本体中使用的词汇可能差别非 常大。2)语义关联的缺失:在进行语义查询时，语义概念或实例之间的关联需要被明确地 表示出来，但在关键字查询中通常这些关联并不会出现。如何自动地发掘这些缺失的关联是 一个问。3)语义查询排序:由于关键字查询通常是带有歧义的，因此一个关键字查询可 能会存在多个语义查询与其对应。如何对这些语义查询进行排序也是一个需要解决的问题。 为了解决这些困难，我们提出了一种有效地将关键字查询转化为 SPARQL 语义查询的 方法。主要分为三个步骤:关键词映射，语义查询构造和语义查询排序。 4.1 关键词映射 关键词映射的目的在于为用户查询时输入的每个关键词找到相对应的语义实体(可能是 [7]概念 Concept、实例 Instance 或属性 Property)。根据，从语义的观点来说，一个关键词可 能会被匹配为 1)本体概念(例如，关键词“email”匹配为 Email 本体中的概念“Email”); 2)本体属性(例如，关键词“subject”匹配为 Email 本体中的属性“messageSubject”);3)本体实例(例如，关键词“allen”在“fullname”属性上匹配 Contact 本体的实例“allen-p”)。 本系统中关键词映射的语义实体对象主要是 Email、SMS、Calendar、Contact 的语义数 据，包括 NMO、NCAL、NCO 本体中的相关类和属性，以及存储在 Tracker 语义存储中的 相关本体实例。为了更高效地进行关键词映射，我们使用了 Lucene 作为索引和搜索引擎， 对 Email、SMS、Calendar、Contact 等语义数据进行全文索引和检索。 4.2 语义查询构造 在完成关键词映射之后，语义查询构造过程用于把用户输入的关键词相对应的语义实体 [8]构造成可能的语义查询。与中采用的方法类似，我们将语义查询构造分为三个步骤:查询 集(Query Set)构造、查询图(Query Graph)构造和 SPARQL 查询生成。 4.2.1 查询集构造 在查询集构造中，各关键词对应的语义实体将被分配到不同的查询集 中。由于每个关键 词可能对应于多个语义，语义实体分配的目的在于为每个关键词指定一个明确的语义含义，这样每个查询集中就包含若干个从不同的关键词映射而来的带有明确语义的实体。通过枚举 出所有关键词的所有语义的不同组合，从而构造出多个查询集。当每个关键词对应于多个语 义实体时，查询集的数量可能会非常多。 4.2.2 查询图构造 在查询集构造完成之后，下一步是为每个查询集生成一个查询图。这个 过程分为两个步 骤:查询集扩展(Query Set Exploration)和查询图构造(Query Graph Construction)。(1)查询集扩展 查询集扩展的目的是在查询集中发现并扩展缺失的本体概念。对于每个查 询集，扫描其 中的每个语义实体，并结合相关本体的定义，在查询集中扩展添加必要的本体概念，以便随 后的查询图构造过程产生出更加准确的语义图。在查询集扩展中，当一个 RDF 三元组中的 本体属性和一个本体实例都出现在查询集中，而相应的本体概念不在查询集中时，这个缺失 的本体概念将被添加进该查询集中，以构造一个完整的 RDF 三元组。查询集扩展的意义在 于，在构造查询图时，扩展的本体概念可以作为其他本体属性的 range，来构造更多的 RDF 三元组。 (2)查询图构造 在查询集扩展之后，下一步就是为每个查询集构造一个查询图。查询图 是由若干 RDF 三元组组成的，每个三元组的形式是<主体，谓词，客体>，其中主体和客体为本体概念或 实例，谓词为本体属性。这些构成三元组的语义实体，可能是从用户输入的关键词映射而来， 也可能是在查询集扩展时加入查询集中。构造查询图时，扫描每个查询集，根据查询集中的 各语义实体的类型，结合相关的本体定义，将各语义实体构造为一个个 RDF 三元组，从而 为该查询集生成一个可能的查询图。 在构造查询图时，各语义实体将对应于查询图中的各个节点和边，其对应关系为:1) 语义概念对应于查询图的变量节点(Variable Node);2)语义实例对应于查询图的端节点 (End Node);3)语义属性对应于查询图的边(Edge)。 4.2.3 SPARQL 查询生成 查询图构造过程将每个查询集转化为一个查询图。接下来，就要 根据查询图来生成最终 ，因此，可以的 SPARQL 查询语句。因为 SPARQL 查询语言是一种基于图模式的查询语言直接地将查询图转化为相应的 SPARQL 查询语句。生成 SPARQL 语句时，遍历查询图中的 每个三元组，按照 SPARQL 查询语句的语法，将它转化为对应的 SPARQL 语句。 生成的 SPARQL 查询语句，主要使用了 SPARQL 的 SELECT 查询方式。SELECT 查询 方式可以获取在指定查询模式中绑定的所有或部分变量的值。 4.3 语义查询排序 在关键词映射和语义查询构造模块之后，用户输入的查询关键词已经被转换为带有明确 语义的形式化的 SPARQL 语义查询。然而，当关键词数量过多，尤其是当每个关键词对应 多个语义实体的时候，不同关键词对应的语义实体间的不同组合数目会很大，因而最终生成 的不同的语义查询的数量可能会非常之多。在这种情况下，对语义查询进行排序就十分重要。 语义查询排序过程对各个语义查询进行评分，并根据分数高低对生成的语义查询进行排序， 分数越高则代表该语义查询越重要，即越可能代表用户真正的查询意图。 [8]对于我们采用的语义查询构造的来说，影响语义查询排序的因素有两个:1)每 个关键词和它对应的语义实体之间的匹配程度。关键词和语义实体间的匹配程度越高，说明 语义实体更能表达关键词的真实查询需求。2)构成查询图的语义实体数量。查询图中的语 义数量越多，我们认为该查询图更加详细准确。由于我们使用了 Lucene 作为关键词映射的 索引和检索引擎，我们可以利用 Lucene 中的相似度评分机制来衡量关键词和语义实体之间 的匹配程度。 在关键词映射阶段，对应于关键词的每个语义实体都会有一个 Lucene 的评分，表示用 关键词检索到该语义实体的评分。构造查询图时，我们计算出查询图中所有语义实体的评分 总和，然后为该查询图计算出一个综合的评分来。为每个查询图计算出一个评分之后，我们 就可以对所有的语义查询进行排序。进一步，可以选出排序最靠前的若干个或一个语义查询 作为用户期望的语义查询，在本体存储中进行形式化的语义查询。 语义查询自动构造模块将用户输入的若干关键词构造成了形式化的基于本体的 SPARQL 语义查询。使用这些 SPARQL 查询语句，可以在 Tracker 语义数据存储中进行语义 查询。本系统中，Tracker 的语义数据存储用来存储移动终端上的 Email、SMS、Calendar、 Contact 等语义数据。语义数据搜索模块负责用自动构造的 SPARQL 语义查询搜索出用户需 要的 Email、SMS、Calendar、Contact 的语义信息。 语义查询模块使用了 Tracker 中查询语 义数据的 API - libtracker-sparql 库。进行语义查询的主要步骤为: 1)创建 TrackerSparqlConnection 连接。 2)调用 tracker_sparql_connection_query 接口，执行自动构造生成的 SPARQL query，完 成 Email、SMS、Calender、Contact 语义数据的搜索。 5 结论 本文介绍了一个基于 N900 移动智能终端的语义桌面搜索系统的设计与实现。系统对移 动终端上用户常用的电子邮件、短信、日程表、地址薄等个人数据进行了语义存储，并支持 词搜索的方式实现对电子邮件、短信、日程表、联系人等个人信息进行基于本体 用户以关键 的语义搜索。通过这种方式，用户可以在移动终端上以熟悉的关键字查询方式，来进行带有 语义信息的个人数据的查询。这样既保留了关键字查询的便利之处，又结合了语义查询的准 确性，从而提高了语义桌面搜索的实用性。 [参考文献] (References) [1] 曾苏，马建霞. 语义桌面研究综述[J]. 图书馆杂志，2009，2:1,11. [2] Gnome. EDS Architecture[OL]. [3] DFKI. NEPOMUK Message Ontology[OL]. [4] DFKI. NEPOMUK Calendar Ontology[OL]. [5] DFKI. NEPOMUK Contact Ontology[OL]. [6] T.Tran, P.Cimiano, S.Rudolph, et al. Ontology-based interpretation of keywords for semantic search[Z]. ISWC, 2007. [7] Y.Lei, V.S.Uren, E.Motta. Semsearch: a search engine for the semantic web[Z]. EKAW, 2006. [8] Q.Zhou, C.Wang, M.Xiong, et al. SPARK: adapting keyword query to semantic search[Z]. ISWC, 2007.