使用推文支持灾难规划，警告和响应外文翻译资料

 2021-12-16 10:12

英语原文共 15 页

《使用推文支持灾难规划，警告和响应》

4.利用工作流程

Twrsms是由一系列子工具集合开发的，这些子工具支持对推文进行收集、消除重复数据、排序、分析和可视化。其中，分析和可视化由ORA工具实现(Carley et al., 2013, Carley, 2014)。展望未来，无论是在哪个阶段，越来越多的减灾系统都是系统体系——包括可互操作组件系统的松散联合，每个组件系统都可以单独使用或与其他组件联合使用。对于国际上使用的系统尤其如此。

在本节中，我们将描述用于收集、分析和呈现推文的通用工作流，以及该工作流的具体实例，包括使用到的设计议题和技术。TWRsms是图5中提出的通用工作流的一个例子。这个工作流程有五个组成部分:

1.集合，即收集推文（推文）。

2.管理，即对推文进行归档和压缩。

3.分析，即对压缩后的推文进行不同的分析。

4展示，通过呈现分析内容来进行评价。

5.集成，该系统可被视为更大的灾难系统的一部分。

图五 我们收集，分析和呈现推文的一般工作流程

在这个过程的末尾，应该从推特流中提取原始推特 JSON，进行压缩，归档并将其转换为有用的结果。

当我们回顾这个工作流的每个部分时，我们为每个部分的实现提供了具体内容。关于收集数据，我们讨论了如何使用推文Tracker来收集推文。对于管理部分，我们讨论了使用一组定制的中间件来从数据中删除不必要推文。关于分析部分，我们讨论了如何使用ORA网络分析工具来对推文进行分析。最后关于展示，我们介绍了存储数据的网站（见图6）。

图6 我们一般工作流程的具体实现，使用了python脚本，java代码和ORA网络分析工具的组合进行搭建。

4.1收集

从推特的流API中收集推文的方法是任何推文获取途径的基础部分。推特给感兴趣的程序员提供了文档以帮助使用该接口来开发工具(推特, 2012)。他们也提供了可以用作建立查询基础的java库。此外，开发人员还建立了一系列免费的库来支持使用其他编程语言访问API，如C ，Python,和Ruby(可查看 swatkat et al., aa1ronham, Michaels-Ober的评论)，访问这个API。即使不会开发一个从这个流API中获取推文的程序也没关系，因为已经存在许多实现该功能的程序了。在这些程序中，少部分是免费的，那些免费的程序通常不为分析提供简化接口或者是支持连接到复杂分析工具，比如DataSift4, Topsy5, Texifter6, Simply Measured7, and HootSuite8 (更多信息参见Orsquo;Brien, 2013, Bruns and Liang, 2012 ).如果这个程序没有给出原生的推特JSON数据，那么就偏离了这里所提到的一般工作流程。

在我们的实现中，起初我们使用亚利桑那州立大学开发的工具推文Tracker，用于从流媒体API收集推文 (Kumar et al.， 2011, Kumar and Morstatter, 2011)。虽然该工具存在一个图形用户界面（GUI）版本，但是我们使用命令行版本以更好地集成到我们的工作流程中。在对系统这一部分进行设置时，重要的是要考虑它是如何交互的；交互越少，就越有必要避免GUI并坚持完全自动化的过程。最近，我们转向直接从推特API中获取数据，因为这样做获取数据的速度更快并且能够对数据的存储方式进行更大的控制。为了检测收集到的推特数据给研究区域的灾难规划和早期预警的质量，一个关注于印度尼西亚推文使用情况的独立研究展开了(Carley et al., 2016).在研究中的其中一部分，研究了许多印度尼西亚整体的，尤其是巴东的推特收集战略。这项研究表明，对于巴东这样的地方来说，最好的策略是首先使用一个边界框来收集推文，然后使用关键词来删除那些研究内容外的推文。第二个最佳策略是同时使用关键字和一个边界框进行收集。附录A提供了巴东的关键字和边界框。需要记住的是，准确的数据收集策略将取决于收集器是购买整个推特 firehose、10% decahose还是使用1%的流媒体API。一般来说，后一种选择是最经济的，足以满足灾害管理的需求(见Carley et al.， 2016)。

基于一系列用户提供的搜索参数，使用流API一次传送能够获取连续流的上限是所有推文集合总量的1%，使用REST接口从推特网站访问的搜索API允许一次搜索多个参数。这个功能带来一系列挑战，并且在一段持续的时间里获取大量推文也很具挑战。这些参数包括关键字，位置边界框，和用户ID（巴东参数参见附录A）。只要是包含其中的特定关键字推文就会被收集。在推特的API中，如果你同时指定地理边界范围框和一系列搜索关键词，推特将两个查找条件的关系看做是或，即推特将提供研究区域内的推文、包含一个或多个关键词的推文或者是同时满足以上两个条件的推文。推特并不支持把所有参数间的关系看做是“且”来获取推文。

我们用于巴东的指定参数于附录A可见。包括了一个涵盖巴东地区的边界框。需要注意的是即使当我们在只指定了一个边界框，进行数据收集时也会获取到研究区域的政治边界外推文。之所以出现这种情况有两个原因：一是边界框只能被指定为一个矩形，然而大部分行政区域都不是简单的矩形；二是，推特为了采样，使用这个边界框来识别推文从哪个面图形找那个取出。任何推特定义的面图形只要与边界框叠加都会用来获取推文。因此，为了保证推文完全且只来自于研究区域，建议使用多个小边界框。正如上面所提到的，我们也检查了查询术语的使用来从API中收集推文或者是在收集完毕后用来移除不需要的推文。我们使用的术语指的是印尼特定的地理位置，印尼俚语中的灾难和政治问题，政治术语和灾难相关术语。Carley等人(2016)的研究表明，在印度尼西亚和巴东，有相当一部分推特用户使用英语，因此我们所有的术语都采用英文和印度尼西亚语两种方式。与灾害有关的术语是基于先前关于人们如何提及灾害事件的研究，并以马斯洛需求层次为导向，侧重于粮食、水、住所、失踪人员和腐败。对于整个印度尼西亚，我们还使用了知名政治人物的用户id，当灾难发生时，他们可能会发送官方消息。巴东位于苏门答腊岛西海岸，特别容易受到海啸的袭击。通过收集巴东和印尼大陆的推文，我们希望得出一套独特的特征，对比当地和全国对海啸的反应。TWRsms旨在支持这种一般性比较。随着时间的推移，我们希望这将帮助我们了解如何将该系统扩展到一个全国性的系统。

每天，从巴东和印度尼西亚的流媒体API收集的数据量分别约为90776和2，617，208条推文。每天的这个数据流大约等于3.1 GB的数据量，但是可以激增到更高的容量。在4月初智利地震之后，“海啸”一词在全球范围内引起了广泛关注，我们发现自己每天都会收集大约20 GB的推文。由于这些激增和关键字的变化，Collection出现了周期性的问题，但是在2014年3月和4月的大部分时间里数据获取都是连续的。印度尼西亚整体的数据没有出现在巴东的TWRsms中，但是研究小组使用它来改进整个TWRsms流程。

收集的推文被格式化为JSON，这是一种轻量级格式，由一系列“键：值”格式的键值对组成，其中包含的值可以是一系列的多个值或其他键值对。 例如，键“文本”映射到收集到的推文文本，键“用户”映射到一组键值对，描述发布推文的用户。 结构语法通常保持最低限度，它由键的名称和分隔符组成，指示特定值是一组值，一组键值对还是单个值。即便如此，我们收集的大约53%的推文信息通常都是由结构性信息组成的。推特还提供了一些长期分析不太可能需要的信息。例如，提取的hashtags和文本中的特定索引都包含在内。对于许多分析，可能只需要hashtags。用户可以使用JSON中提供的hashtags，根据JSON中提供的索引验证它们的存在，或者编写自己的代码来定位hashtags。最后，所提供的一些数据将被去除。为了处理这些多余的数据，我们转向工作流的下一个阶段。

在这一点上，我们的经验表明，最好的做法是使用一个限制框来收集推文，以确保覆盖范围。并且只使用用户id进行第二次收集——以确保获得官方推文。然而，大多数收集到的推文都与灾难无关。在规划和预警阶段，这是可以的，因为在这些阶段收集数据的目的是估计人口及其位置，并跟踪官方警告。然而，在灾难发生期间和灾难发生后不久，关键将是将推文限制在研究范围内。我们在管理部分下讨论如何做到这一点。最后一点，我们注意到推特社区正在不断发展;因此，需要自适应地修改所跟踪的任何术语、用户id，以及在较小程度上修改边界框。例如，如果印度尼西亚跟踪的某个推特帐户似乎已经停止发布推文，或者被垃圾邮件发送者接管，则应该从搜索查询中删除该帐户。相应地，如果我们重复捕获经常使用我们抽样的关键字的用户的推文，我们可以将该用户添加到我们抽样的帐户的一般列表中，因为即使没有使用某个已建立的关键字，这些评论也可能是有用的。通过调整我们的样本，我们可以更好地收集和/或事后确定我们认为真正重要的推文。

4.2管理

在这个章节下，我们关注于清洗收集到的数据。为了减少存储花销，同时保留一个有意义的数据子集，我们把概要数据——而非存储原始数据，存储起来作为TWRsms的一部分。这些数据还进行了转换以方便使用像ORA这样特定的分析工具使用。仅存储汇总统计数据的另一个原因与收集个人数据的道德规范有关。虽然收集的数据在收集时是公开的，但个人可以决定将其数据设为私有。通过只存储摘要数据，我们可以保留准确的摘要，而不需要保存特定的推文或单个记录;因此，有效地消除了个人可识别的信息问题，并含蓄地遵从了未来将数据变为私有的愿望。

最安全的做法是，将收集到的推特 JSON与存档时的位置分开操作。最佳实践是将数据复制到临时位置进行清理，然后将其移动到最终存储位置。最后的存储区域可以是数据库，也可以是平面文件的集合。无论哪种情况，执行清理和传输都需要某种中间件。

在我们这种情况下，这些中间件由一系列Python脚本和一个Java管理程序组成。当推文Tracker收集到推文时，它将文件存储到用户指定的文件夹里。我们使用Python脚本来把这些文件复制到一个临时的工作空间，在传输后移除这些原文件。我们的脚本清除工作数据，将其复制到存储位置，然后清除工作文件。在任何时候，此过程将所需磁盘减少到接近原始文件所需的磁盘。

Python脚本(以及整个流程)的清理元素在一定程度上是由于原始数据流的变幻莫测而必需的，流API通常提供一个混乱的原始数据流；从API收集的JSON可能被破坏或不完整；它可能被截断或缺少特定的键，并且可能包括重复的推文。流式API定期向用户提供样例中省略的推文的数量，以及断开和重新连接到流的记录。这些记录可以提供额外的信息，但是对于只期望获取和推文映射的JSON数据的工具来说，这些记录可能会造成问题。如果正在使用这样的工具，则需要清除这个JSON。我们还注意到，推特定期更新定义推文的JSON标准，如果您使用数据仓库服务来整理推特JSON，提供者可能会向数据添加额外的“键：值”对。如果是需要需要特定的数据结构的分析工具，则此类更改可能会导致该工具丢弃整理的推文。这些附加字段可能需要从数据结构中清除。因此，我们的Python脚本会清除格式错误的推文、推特关于断开连接的定期警告以及丢失推文的数量。此清理过程还包括清除研究内容外的推文并按日期重新组织推文 JSON。使用Python脚本清理元素在一定程度是因为我们希望从集合中清除所有不需要的推文。流API将返回与所指定搜索条件中任何参数匹配的推文。关于预警和规划，理想化的，我们期望的是所有带地理标签的来自研究区域的推文。正如Carley et al. (2016)提到，这是不可能的。我们注意到。即使是最全面的收集，也会包含不在该地区的推文和不是由人类发布的推文；例如，机器。因此，移除不需要的推文的第一阶段仅仅是移除不是来自研究区域或者是机器发布的推文。我们可以放心移除那些经纬度位于研究区域外的推文。推特用户也可以设置他们研究区域的时区；因为印尼位于UTC 7, UTC 8, and UTC 9三个时区中。一般来说，我们可以移除那些时区外的人发布的推文。基于纬度、经度和/或时区的清洗策略可能会有明显不同的结果，这取决于数据最初是如何收集的；例如，使用此清洗策略对于印度尼西亚收集的数据来说，8.72%的推文被认为是不相关的，而对于Padang来说，38.24%的推文被认为是不相关的。原因是，当在收集数据中使用一个边界框 术语时，如果该区域内的推特用户数量较少，那么获取到的推文来自于根据术语进行获取的会多于按照地区获取的，由于巴东的推特用户比整个印度尼西亚的推特用户要少，使用这一收集策略使巴东比印尼收集到更多不相关的推文。只按照边界框进行收集能够实际减少收集到的不相关推文的数量。使用这个方法只有2%的推文表现出不相关。至于机器发布推文，尽管我们目前为止还没有在TWRsms中对这点进行完善，但是我们注意到机器发布的推文能占推文的一大部分——有时能够达到总推文的25%。有一个研究估计几乎一半以上的推特帐户是机器账户（俗称“僵尸账户”）。这些机器发布的推文可以完全控制数据和统计，影响我们从中的判断和分析(Morstatter et al., 2015, Wei et al., 2015)。通过边界框来收集数据也许可以减少获得的机器生成的推文，但不会消除这些推文。也许最好的方法是通过机器学习的工具来识别和移除这些机器账户和推文。在TERsms系统中现未集成这样的工具，但是，已经计划在下一个版本添加。当清理脚本将推文移到整理区域时，它会根据它们的时间标记对它们进行重新分组，每小时一个文件。这简化了归档过程，并对数据进行分组。删除带有错误地理标签或不适当时区的推文后，我们的巴东数据收集量每天约有40，291条推文，而我们的印尼数据收集中每天约有1，094，989条推文。(相当于源数据的44.39% and 41.84%) 我们的第二个中间件

资料编号：[4861]

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章