英语原文共 23 页，剩余内容已隐藏，支付完成后下载完整资料
上下文感知浏览器
Paolo Coppola1, Vincenzo Della Mea1, Luca Di Gaspero2, Danny Mischis1, Stefano Mizzaro1, Elena Nazzi1, Ivan Scagnetto1, Luca Vassena1 *
1 数学与计算机科学系
2 电气，管理和机械系
乌迪内工程大学
意大利
coppola@uniud.it, dellamea@dimi.uniud.it, l.digaspero@uniud.it, mischis@dimi.uniud.it, mizzaro@dimi.uniud.it, elena.nazzi@dimi.uniud.it, scagnett@dimi.uniud.it, vassena@dimi.uniud.it
*作者按字母顺序列出
相应作者：Stefano Mizzaro电子邮件地址：mizzaro@dimi.uniud.it
完整邮寄地址：乌迪内大学数学和计算机科学系 - Via delle Scienze，206- I33100 Udine - 意大利
电话和传真号码： 39 0432 558456 39 0432 558499
摘要：我们提出了上下文感知浏览器，这是一种通过移动设备对上下文感知Web内容进行阅读的新方法。上下文感知浏览器利用人工智能技术并混合了以下几个
要素：它是运行在某人自己的移动设备上的Web浏览器，能够自动主动地下载和执行上下文感知的Web内容，通过根据上下文查询搜索引擎来选择。所提出的方法的新奇之处由两部分组成。首先，我们考虑周围环境提供的信息，以便对Web内容进行更加精细的搜索。其次，信息不仅自动推向移动设备，然后进行过滤：当然，CAB（上下文感知浏览器）方法包含一个两阶段检索加过滤过程，可最大限度地降低带宽，隐私和安全风险。作为总体结果，用户所需付出的努力也被最小化。
引言
用户通过传统浏览器在Web上搜索信息的典型方案需要一定程度的重大努力才能获得所需的信息（网页，应用程序，资源等）。用户使用网络搜索引擎（例如Google）必须提供查询，并且她还必须检查结果，以查看他们是否真的提供了所需的信息。否则，查询必须被细化，重新提交等等，从而产生一个迭代过程。
因此，从认知角度（考虑提交正确的查询，检查获得的结果）和实践角度（大量的按键，屏幕卷轴：总之与用户界面的许多交互）两方面来看，上述信息搜寻活动对于最终用户来说相当麻烦。如果这种情况对于日常使用桌面系统的计算机科学家或熟悉这种交互的人们是可以接受的，那么在PDA或移动电话上执行同样的任务就成了一个严重的问题。事实上，与传统PC上的对应设备相比，这种设备的图形用户界面和输入/输出外设相当有限; 此外，用户往往是一个不太熟悉计算机应用程序和搜索引擎通常运作方式的人。尽管如此，在信息扮演一个至关重要的角色的当下，即使我们远离传统计算机，快速获得所需信息也是有用的，甚至是至关重要的。例如，在机场，可以通过自己的移动电话接收她的航班的详细信息（登机柜台的位置，登机口号码等），而不必花太多精力检索这些信息对乘客来说是大有益处的。此外，最好的解决办法是开发一种基础设施，一旦乘客抵达机场，就能“自动”提供这些数据。
窗体顶端
窗体底端
另外，当前搜索引擎的另一个重要的，争议较多的限制是在用户提交查询时必然忽略用户所处的“环境与背景”。这种“忽略”意味着生成的答案取决于查询本身，而不会考虑许多能够以有用的方式优化结果集的数据（由潜在的环境给出），从而为用户提供更合适和可利用的信息。回到前面的例子，可以使用一个简单的事件例如乘客到达（可以通过她的手机的蓝牙设备发现），能够用来决定她当前所处的环境“该用户已经在飞机场”。然后，如果乘客用关于航班号的笔记更新了她的日程，那么这些数据可以通过合适的“背景”应用程序传达给机场服务器（例如再次利用蓝牙连接），以便收回航班的详细信息。在这种情况下，接收航班号的事件将丰富先前推断的情况，从而确定“用户在机场以便乘坐特定航班”。这反过来可以自动生成进一步的信息“推”到她的手机。请注意，在整个过程中，除了启用移动设备的蓝牙天线并激活上述“智能应用程序”之外，不需要用户付出任何其他努力。当然，上述情况会带来明显的隐私和安全问题：人们可能会要求将他们的位置保密，至少在某些情况下; 在自己的手机上下载的数据可能是恶意软件; 等等。因此，必须实施适当的政策和机制，以保护存储在移动设备上的敏感信息并确保用户的匿名。
窗体顶端
窗体底端
拥有这些想法，我们提出了一种新的网络内容实现方法，即所谓的上下文感知浏览器（简称CAB），它将扮演“智能应用程序”描述场景中的基本角色。更详细地说，CAB将能够从周围环境中收集数据，搜索适合当前上下文的网页内容，自动加载和显示选定的网页内容，并自动提供网页和网页应用程序。构建一个具有如此复杂行为的应用程序根本不是一件简单的事情：如下所述，不同的人工智能技术被利用，它们对于有效的CAB是至关重要的。
本文的结构如下：第2节中，我们简要地回顾了在上下文感知和移动计算领域的一些相关工作。第3节中，致力于说明CAB总体结构。第4节中，考虑单个模块。第5节中，介绍了典型的使用场景。第6节中，讨论了评估价值问题。
第7节中，讨论了最终考虑和未来工作。
相关工作：上下文感知和移动计算
几个研究领域与我们的方法相关。我们简要回顾在上下文感知，上下文感知检索和基于上下文应用的框架方面所做的工作。我们将更深入地讨论MoBe框架，因为它将在下面清楚地表明它是CAB发展的基础。
2.1上下文感知
2.1.1上下文
上下文的概念仍然是一个讨论问题，并且多年来提出了几种不同的定义。它们可以分为外延和内涵的定义。
外延定义通过一系列可能的上下文特点和他们的值来呈现上下文。第一个工作是介绍如何表示上下文感知[22],上下文由用户的位置和周围的对象来表示。相似地，Brown[6]等。将上下文定义为位置，与他人的距离，温度，时间等。在[17]中，上下文的概念分为三类：计算机上下文（网络，显示等），用户上下文（个人档案，人际关系，社会状况等）和物理上下文（光，噪声等）。Chen[8]等人，添加两个其他类别：时间上下文（日，月等）和历史上下文。
内涵定义更正式地呈现上下文的概念。在[1]中，上下文被定义为“可用于表征实体情况的任何信息”。实体是一个人，地点或者是被认为与用户和应用程序之间的交互相关对象，包括用户和应用程序本身。对于Brazire和Brezillion [3]，上下文就像一组影响嵌入给定任务中的系统（用户或计算机）行为的约束。
该定义从分析一个包含150种来自不同应用领域比如社会学，科学等的上下文定义集合中得到的。
外延定义似乎在实际应用中很有用，因为抽象的上下文概念必须具体化。然而，从理论角度来看，它们并不完全正确，因为上下文不能仅仅由其某些方面概述。另一方面，内涵定义在实践中几乎没有用处，尽管它们在理论上是令人满意的。
2.1.2上下文感知计算
上下文感知计算可以被定义为软件应用中上下文的使用，其中应用通过改变它们的行为来适应发现的上下文[8]。从外延的角度来看，上下文感知应用程序具有以下特性[18,11]：上下文感知，向用户呈现信息和服务，自动执行服务以及为信息添加上下文以供日后检索。
在大多数较早的上下文感知应用程序中，上下文的概念仅包含少量数据。例如，大多数研究集中于时间和/或位置以及其他一些数据[28,24]。更复杂的方法倾向于结合几个上下文值来生成新的上下文信息。在主要的上下文中，位置，实体，活动和时间，作为其他上下文信息源的索引。同样，在TEA项目[23]中，Schmidt等使用解析层来确定从基本上下文信息开始的用户活动。
正如在前面引用的作品中，我们打算结合上下文来确定新的更抽象的上下文。然而，与他们不同的是，我们不想仅仅根据先验定义的背景维度来限制推论，但我们的目标是开发一种能够以一般方式工作的推理基础设施。
2.2上下文感知检索
上下文感知检索是一个相当新的充满了兴趣的领域，随着上下文感知应用程序的兴起和他们管理的信息量的增加，上下文感知检索的重要性已经增加。该领域的第一项工作是实时信息检索代理：一类软件代理，以易于访问和不显眼的方式，以一般，任务无关的方式主动呈现基于人的上下文的信息[20]。上下文感知检索可以描述为经典信息检索的扩展，将上下文信息合并到检索过程中，目的是在当前上下文中提供与用户相关的信息[7,14]。
上下文感知检索模型包含以下元素[7]：
- 一组不连续的文件；
- 一组在查询中捕获的用户检索需求；
- 一个检索任务，提供与当前查询最匹配的文档，根据相关性度量进行评分;
- 用户的上下文，用于查询制定和关联作为检索候选的文档
可以确定两种不同的方法[7]：用户驱动和作者驱动。在前者中，根据用户的上下文，可以自动发出检索请求; 在后者中，集合中的每个文档都有一个触发器上下文; 如果它匹配用户的当前上下文，则检索文档。
通常情况下，上下文感知的检索应用程序具有以下特征[14]：
- 用户的流动性，一个用户的上下文总是在改变。
- 如果不需要咨询用户，则采用交互式或自动操作;
- 时间依赖性，因为上下文可能会改变;
- 适当并安全地打扰用户。
上下文感知检索正在快速增长。最近一项用户调查[26]证实，用户希望获取上下文感知检索应用程序：20位参与移动信息需求研究的参与者被问及他们如何看待能够预测其信息需求并在适当时间提供适当信息的工具;85％的参与者积极响应，而只有15％的参与者对隐私和控制问题犹豫不决。
2.3架构
2.3.1 Stick-e Notes
Stick-e Notes [5，6]是一个围绕Post-its的电子等价物概念开发的框架：用户可以将笔记（文本，HTML页面，声音，视频，程序等。）关联到不同的上下文（地点，时间等。），以便当事件再次发生时，相关笔记将被激活。这个框架被认为是构建上下文感知应用程序的基础。
2.3.2Cooltown
Cooltown项目[15]旨在建立一个基于Web的上下文模型，尤其是“Web Presence”；的确，主要想法是将虚拟服务与物理实体相关联。这种方法的动机是许多数据库和网页包含大量有关物理世界的信息; 然而，这些信息仍然与后者“分离”。因此，物理实体被分为人，地点和事物（因为在他日常生活中的人可以遇见人，移动到不同的地方并与事物交互），并且他们的相对访问形式被扩展到网络内容的虚拟世界，其中人们，地点和事物通过“Web Presence”上下文来表示。
2.3.3Context toolkit
Context toolkit [10]是GeorgiaTech多项研究活动的结果，旨在构建支持上下文感知应用程序开发的体系结构。整体方法是面向对象的，以三种对象为特征，即小部件，服务器和解释器。上下文小部件本质上是软件组件，将应用程序与上下文觉察绑定的活动隔离开来。它们是由属性（其他组件可用的上下文信息的“片段”）和回调方法（表示可由小部件唤醒的事件种类）定义的可重用组件。上下文服务器是收集器，用于收集特定实体的整个上下文，例如用户; 他们必须向他们感兴趣的每个小部件注册自己，充当应用程序的代理。 最后，上下文解释器管理上下文数据的解释，允许以不同的格式呈现这些信息，并将多个上下文数据合并成新的信息。
2.3.4 Sparkle
Sparkle [25]是一个上下文感知应用程序级状态管理平台。它基于上下文感知状态捕获和恢复机制，可以实现上下文感知应用程序迁移。在Sparkle系统中，应用程序由facet组成。facet是纯粹的功能单元，独立于数据或用户界面。facet不与用户交互，也不维护任何应用程序状态。因此，每个应用程序都与一个容器相关联。容器包含用户界面并存储数据和执行状态。它还存储应用程序可以提供的一组功能。facet位于网络上的facet服务器上。应用程序在执行过程中会请求某个功能。可能有不止一个facet实现相同的功能。在运行时，引入并执行最适合运行时环境的facet。
2.3.5Hydrogen
Hydrogen[13]是一个分布式上下文感知应用程序的框架，基于没有集中组件依赖的思想。Hydrogen是一种体系结构，它不仅包含本地设备的上下文，而且还可以代表远程设备的上下文。在遇到另一个设备的情况下，上下文信息可以相互交换（通过WLAN，蓝牙等）
全文共21008字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[11633]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
