Opening the Black Box of Social Media Research Methods: SoMe Ways Forward

Transcription

1 Opening the Black Box of Social Media Research Methods: SoMe Ways Forward Work in progress by the SoMe UW: Joe Eckert*, Shawn Walker, Jeff Hemsley, Karine Nahon, and Bob Mason * orresponding author, jeckert1@uw.edu Abstract This workshop reports on a research effort that spans about 15 months. It describes how we have collected data on the Occupy Wall Street (OWS) movement, how we prepared this data for analysis and visualization, and the choices we have made in getting this far. We start from the position of social scientists (although several of us have technical backgrounds) because we became familiar with the difficulties and hurdles researchers face when attempting to research phenomena involving social media artifacts. We prepared this workshop so that you can learn from our experiences: what went right, what went wrong, and what could have been done better. You ll receive a first look at the SoMe Lab Toolkit, a work in progress that we currently use to query and analyze an extensive corpus of Twitter data. Moreover, by attending this workshop you also have the ability to shape this project-inprogress by sharing your own personal research needs and desires. Although our current project focuses on Twitter, the development of the platform as well as this workshop is oriented toward a more holistic practice of social media research across platforms. We want to help you make your research better, just as we hope that your input can improve our toolkit -- and you ll be first on the list to receive more information and software releases! 1. Context and Background Our Social Media Lab (SoMeLab.net) effort began because three of the founders shared an interest in social media as a means of social change. We began collecting data about the Occupy Wall Street (OWS) movement and found that Twitter appeared to be a hub for social media communications. Consequently, we directed much of our attention on collecting Twitter data, and we have amassed a collection of over 100 million tweets. As we examined the related literature, we discovered two things: social media research is popular; and most empirical papers were not very clear about the foundational assumptions and methods underlying the research. This is understandable--the decisions and assumptions in collecting and analyzing social media data can be complex and often require numerous tradeoffs. Adequately covering these complexities and tradeoffs would result in excessively long papers. However, the lack of detail about method and procedures constrains what other researchers can learn from such studies and limits the generalizability of the findings. We wanted to change this situation. What follows is a discussion of our own work on social media and the lessons we feel we have learned from our experiences. The objective of this synopsis is to sketch a framework for social media research decisions as we have experienced them. We provide examples of how HICSS Workshop 2013 Research in Social Media SoMeLab.net page 1

2 we made these decisions in our collection and analysis of Twitter data related to the Occupy Movement. We make no claim that this is an exhaustive list of choices or that the framework we describe will be best suited for everyone or even for us as we progress. This is clearly a work in progress. Our research continues, aided by almost $1 million from the US National Science Foundation [IIS : INSPIRE: Tools, Models, and Innovation Platforms for Research on Social Media]. One objective of the NSF-funded project is the development of an open source toolkit that will be shared with other researchers who may not be prepared to undertake the necessary technical development on their own. This HICSS workshop is an opportunity for us to share what we have learned so far and to get comments and feedback from participants. We would like the workshop to contribute to a widening conversation among social media researchers. We hope this conversation will enable the continual improvement of methods and a broader base of shared empirical studies. 2. Introduction This document is designed to offer insight into the decision-making processes that feed into methodological strategies for social media analysis. This accompanies the demonstration of the alpha version of SoMe Lab s Toolkit for Social Media collection and analysis. Far from an exhaustive review of analytical techniques, we use our own experiences collecting a corpus of social media data captured as relating to the Occupy Wall Street set of contentious politics and tactics (although not all data are related and not all related data can be captured). Using our own experiences as a case study, we hope to meet two objectives: First, we hope to illuminate some of the decisions that are often black boxed within academic writing about social media analysis. Second, we d like to inform some of the decisions you re likely to be making in your own social media projects, offering some considerations that are not obvious at first glance, difficult to derive from the Twitter documentation for developers, and may be costly to change later in the process. 3. Overview This document traces the different decisions we ve made and the possibilities for alternate decisions in light of heterogeneous research needs. We primarily review methods involving Twitter, as this is the first platform we elected to tackle in our study. We first cover the process of selecting a phenomenon to study, explaining what we chose. Next, we review the multiplicity of platforms available to social media researchers and provide an explanation of our decision to use Amazon Web Services in our own work. After describing platform selection, we then delve into the thorny question of exactly what data to capture, what options you have available to you via Twitter s set of APIs, and the reasons we selected the streaming API as an appropriate means of capturing an emergent event. Before you start, consider this: Social media data are ephemeral; site and links change often. URLs disappear, content changes, and pictures are removed. A good heuristic is to collect (meta) data as close to the time of posting as possible. Each social media platform has its own formula for matching keywords; be sure to understand this before you start collecting data. Different approaches are required for point-in-time (snapshot) vs. longitudinal data collection (curation of dynamic information). HICSS Workshop 2013 Research in Social Media SoMeLab.net page 2

3 After this overview we further outline the keyterm selection process of the streaming API by discussing rate-limiting, the processes of ongoing data curation, and how to handle the noise inherent in the data collection process. We briefly cover the often labyrinthine terms of service provided by Twitter to developers and how they might relate to you as a researcher. We conclude this document with a consideration of possible ethical dilemmas that a social media analyst might encounter. 4. A Research Method Outline The following is not the only procedure one can chose, but this outline gives us the opportunity to discuss the choices we made in our work. Your approach may differ, but we expect that you ll be making similar choices and tradeoffs. 4.1: Selecting a phenomenon The first step to any good research project is to figure out what exactly it is that you re supposed to be researching. Ideally, this might take the form of a well thought-out research question, particularly if you take a deductive approach to research development. However, sometimes quickly emerging events and the ephemeral nature of Twitter require a more inductive approach. We ll consider both methods in turn, and then explain why we opted for a grab it all and sort it out later approach with our own Occupy-related corpus. In general, it is best for academics to think of Twitter data as being ephemeral. Collecting (historical) tweets about a past event is either prohibitively expensive or not possible. This means that for a deductive approach we would need to know details about an event before it happens. There are many ways to do this. For example, you might be able to leverage existing connections within a community in which you re interested to determine future activities or topics of interest. Alternately, depending on the community, you may be able to derive this information from public meetings, listservs, personal communications with community partners, news publications, or observed use of social media platforms. This comes with two shortcomings: first, even well planned events can unfold unpredictably and spawn relevant data streams that may not be in the scope of the original search criteria. Second, a sudden emergent event could be relevant to a research agenda, but waiting to collect data until a solid research question is formed could result in missing an opportunity to collect critical data. Emergent events may demand a more inductive, grounded approach to data gathering. There are a number of ways that you can go about this, but we recommend participant observation as an initial approach to understanding how Twitter might be viewed by an end-user with an interest in the topic. Some questions you might ask yourself: is there anything having to do with my topic in the trending topics display from Twitter? Is there a website that participants in the phenomenon are using to organize collaborative work or workspaces? If you look at a highly used hashtag, are there other hashtags that frequently cooccur with that hashtag? By encountering Twitter data in the wild, you will gain a better sense of the limited perspective of a single user within the system. For our Occupy data corpus, we took an inductive, grounded route that we affectionately refer to as the baleen whale approach, named for the grand beast that filters delicious plankton from gallons upon gallons of ocean water. We hopped onto Twitter, looked initially at the hashtag HICSS Workshop 2013 Research in Social Media SoMeLab.net page 3

4 #ows, and found two major points of interest: first, an organizational site named OccupyTogether maintained a list of relevant hashtags, account names, and occupied locations via crowdsourcing. Second, we found a number of event-related tags, like #nov5 ( Bank Transfer Day ) that would have gone unnoticed without continued monitoring of related tweets and accounts associated with Occupy Wall Street. A careful accounting of related terms also forces the researcher to consider issues related to rate-limiting and the shifting representations of hashtags, covered later in this document. But first, we have to figure out where to place what will be a growing social media corpus. 4.2: Pick a computing platform In picking a computing platform with which to collect data, you will have to balance price, processing capabilities, storage, resources available to you and your organization, and the type/amount of data required to address your research project. It is worth noting that there are several paid solutions to social media data gathering available in the market that might be acceptable to your needs. However, no chain of custody exists for these data; you re reliant on third-party vendors to accurately provide the data which you re requesting. In many cases these tools do not explain how the data were collected, processed, or analyzed. In response to the limitations and expense of commercial tools, we are developing the SoMe Lab Toolkit which offers the capability to capture data in the raw as an alternative to third-party dependencies. We have successfully installed our toolkit on desktop, cloud computing services, and high performance computing environments. Using a desktop computer or laptop for data collection, analysis, and visualization is possible. This approach has three advantages: desktop processing is comparatively inexpensive, requires little knowledge of high performance computing environments, and may be more than sufficient for communities of interest using Twitter in a way to produce a smaller dataset. The desktop approach also has significant limitations, and these drawbacks warrant considering other computing platforms. A key requirement is that data collection requires constant connectivity; an interruption in connectivity means a potentially irretrievable loss of data, and a complete data collection may be essential to the research. Other limitations are the potential need for faster computation, larger memory, and even larger storage than the typical desktop/laptop solution can provide. Other solutions include services that might be provided by the department or university or commercial cloud-based services such as Amazon Web Services (AWS) or Rackspace. Factors affecting the choice of services include the financial ones of price (set up and ongoing), technical support (responsiveness), and sustainability. 4.3: Collect the Data The data you re able to collect and consequently explore depends on several factors: your computing capacity as described above, the application programming interfaces (APIs) to which you have access for a given platform, the resources made available to you via these APIs, and the methods by which you perform your collection. These are all interrelated issues that change drastically given a difference in platforms. The SoMe Lab Toolkit is initially constructed to gather and explore Twitter data, so we ll be using Twitter as a means to explain what some of these ramifications look like, with a particular attention to different APIs available within Twitter HICSS Workshop 2013 Research in Social Media SoMeLab.net page 4

5 and how that might shape your research methodology. We conclude with a few initial considerations about the actual process of exploration, keeping in mind that this might look differently depending on your research goals. Twitter has numerous APIs that we will not describe in detail in this document. Twitter s documentation for these APIs is written for developers. It can often be quite confusing. Each of these APIs has a specific purpose, and each comes with its own list of advantages and disadvantages. As a result, researchers must spend time pondering which API would fit best with their research. We ll focus on two specific APIs that a great deal of current research tends to utilize: the Streaming API and the Search API. We use the Streaming API in order to obtain real-time ephemeral data from Twitter s network. The streaming API has two main advantages over other APIs in the REST architecture. First, the rate limits are higher allowing users with the default level of access to receive up to 1% of the Twitter stream at any point in time. Second, the streaming API pushes data out rather than forcing the software on the user s end to check for additional data at regular intervals (polling). The remaining components to the REST API are focused on the development of client applications or accessing specific user s Twitter streams -- each of these require authorization from the user. The Search API does not offer real-time access to tweets. Instead, it offers historical access to tweets over about a 6-9 day window. Unlike the streaming API, this is not intended to be an exhaustive collection of tweets that match the terms of your search query, so it s unlikely to be useful unless you have an extremely small amount of tweets to collect. Likewise, you can t assume that the returned results represent a random sample. Twitter documentation is frustratingly opaque about how the method by Twitter selects which tweets you receive. In our work, we elected to utilize the streaming API. The Occupy Wall Street event was emergent, and we expected related events to outlast the 6-9 day window of the Search API. We anticipated the volume of tweets gathered to be fairly extensive and suspected that the rate of collection might vary from day to day. Our research team enjoys sleeping, so we thought it best if we didn t need to manually poll the Search API on a regular basis. Many of our team members have quantitative backgrounds, so curating an exhaustive collection of tweets that matches our list of keyterms would give us a more reliable sample and allow us to consider it complete with regard to our keyterm match. We didn t utilize other REST API components because authorization via the user would have drastically limited our ability to react elastically to changing events, as well as making the process of IRB approval considerably more onerous. Our team is unable to code mobile applications at this time, so we thought it best to spend our energies elsewhere. 4.4: Explore and Refine the Data Our experience suggests that iterative data exploration should be a priority in the development of your research project. At the most basic level, initial data exploration ensures that your collection system is working properly and that you re collecting the types of Tweets you re intending to collect. You ll also be more aware of rate-limiting events as they happen, and will allow you to tweak your keyterm list to account for under- or over-collection. If your approach is deductive or quantitative in nature, it may not make sense to iterate the keyterm gathering list over time; however, as explained above, it isn t terribly difficult to query out specific components of your dataset. This means that keeping the original and subsequent HICSS Workshop 2013 Research in Social Media SoMeLab.net page 5

6 revisions of your keyterm list (with dates!) will allow quantitative members of your team to iterate their samples according to the keyterms collected over a given date range. It still remains important to continue looking at your keyterm collection list in conjunction with the data you re gathering, largely owing to the mutability of hashtags as explained above. If your approach is inductive or qualitative in nature, you ll almost certainly want to iterate your keyterm gathering list over time. Our system currently does not deal with this issue automatically, but it is feasible to count terms that co-occur with your already existing dataset using database queries. One other possible approach is to stake out a participant observer who is responsible for monitoring various Twitter datastreams. The difficulty lies in creating a plan for continual iteration at the outset of your project; without such a plan, ongoing curation of the dataset becomes increasingly difficult. As one aspect of data exploration, we encourage you to engage with Twitter (or other focal social media platform) whether you are taking a quantitative or qualitative approach. Within our own team, we ve noticed that members who are versed in the norms of a social media platform can (sometimes) discern bot accounts from non-automated users, topically related information from marketing ploys. These experienced members generally gain a feel for the mutability of the topic through everyday living on a social media platform. Moreover, the social media platforms are a wonderful outlet for research outreach to communities outside the ivory tower and the feedback can be insightful. Regardless, you ll need to initially explore the data you receive to determine if your research questions and methods remain appropriate. Depending on the type of research you are doing and how much data you are collecting, this can be as simple as scanning the tweet text or as involved as creating network visualizations to get a sense of the complexity of relationships among actors, groups, and meta-data. Simple descriptive statistics can give you an idea of what s in the data, but maybe not the correct idea. Reporting the average will not tell the story if your data is multi-modal or is distributed in a non-normal way. Statisticians have long advised plotting your data as way to help you make sense of it, but when your research questions are complex or you have a massive dataset, you face a number of challenges. Here are some examples: Which fields to use: Twitter returns more than 20 meta data fields, many with sub fields. Often it is necessary to extract a small sample of documents to get familiar with the structure of the data. Be aware that Twitter returns different fields in different cases and adds new fields from time to time. Also, don t assume a consistent data type: retweet count was limited to NULL, 1:99 and Volume of data: Count before find is a good rule of thumb for saving time. A find on all Tweets with OccupyOakland, depending on your settings, can return more data than you really want. Note that programs like Excel work well on datasets with less than a few tens of thousands of rows, otherwise consider using some other tool (R, SPSS, SAS, Stata, etc...). HICSS Workshop 2013 Research in Social Media SoMeLab.net page 6

7 Multiple Plots: The same dataset can look very different depending on how you plot it. The same dataset was used for each of the plots in the diagram above. Multiple plots allow us to examine the data in different ways, but this approach raises some cautions. For example, the plot on the bottom left and bottom right use different techniques for sorting, which could lead to different interpretations. Often the data are complex and standard types of plots - line, bar, pie, network - do not help in understanding what you have or in communicating it with others. Suppose you want to get a sense of the changing volume of tweets, retweets, user participation and user intensity on a given set of tweets. You can print many plots and compare them, but can also iteratively experiment with different ways to visualize the data as a whole (see the bottom left and right corners of the plot above). Visualizations can offer a means by which to holistically evaluate large datasets that would be too time-consuming to analyze as individual artifacts. Equivalent to histograms or data plots for quantitative samples, such diagrams can be especially helpful in emergent research or grounded theory approaches. In exploratory research, visualizations can be generative (suggest hypotheses or theories), confirmatory (for postulates or initial ideas), and test the limits of more established models. 5. Other Concerns 5.1: Complexity of keyterm search Whichever decisions you elect to make, whether they be inductive or deductive approaches, search or streaming APIs, ongoing curation or static keyterm sets, the selection of keyterms is a key component to robust social media research design. Selecting keyterms is more complex than we envisioned. The choice has a myriad number of pitfalls that we initially didn t expect. This section is summarizes how keyterm matching operates and offers some suggestions regarding keyterm selection constructed from our own experiences. First, it helps to know a little bit about how what a keyterm list is and how it operates in relation to the data. For Twitter, the public end point offers a very generous match. If the HICSS Workshop 2013 Research in Social Media SoMeLab.net page 7

8 keyterm appears in the text of the tweet, the URL (extended URL?), or within the text of mention, the entire Tweet and its associated metadata is relayed through the API for capture. So for instance, if your keyterm is chicken, the tweet This chicken is finger lickin good! would be captured. This is not limited to hashtags, although many researchers elect to focus on hashtags as either an initial means or their entire means of keyterm selection. Regardless of what keyterms you select, you re likely to run into some difficulties along the way. We discovered that the actual selection of keyterms is a bit trickier than we initially guessed, judging by some of the barriers we ve seen within our own work. These can roughly be grouped into three categories: issues with the volume of tweets, issues concerning the mutable qualities of keyterms and hashtags, and issues regarding the (often misunderstood) noise issue within data (borrowing the more formal terms from information searching, we might refer to this as the precision and recall issue). Volume. The volume of the tweets you re collecting over time is of primary concern because of rate-limiting. Rate-limiting is the process by which the Twitter API detects your project collection exceeding the 1% sample granted by default levels of access, which causes tweets exceeding this amount to be discarded. Moreover, the process of rate-limiting remains black boxed; we re unsure whether or not this is either a representative or random sample. Because of some of the complications with real-time database services that don t necessarily serve queries in temporal order, we think both situations are highly unlikely. Once you re rate-limited, you no longer have a complete sample for that keyword, nor do you have a representative or random sample. This forecloses certain modes of research. Keyterm selection has a lot to do with whether or not you experience rate-limiting in your own project. Extremely popular terms can instigate rate-limitation. For instance, two of the most popular hashtags on Twitter, #p2 (progressive political tweets) and #tcot (top conservatives on Twitter), will find you nearly immediately rate limited using the default 1% sample. This means that monitoring your collection for rate-limitations during the initial deployment as well as periods where a keyterm might see a significant increase in usage. Within our own work, we found that our 176 keyterms (one of which was #ows, the main keyterm for the movement) allowed us to stay below rate-limitations. Mutuability. You may find that (some) keyterms are mutable in unexpected ways. This seems to particularly happen in cases where hashtags are being selected for keyterm match. We ve noticed in many cases that long hashtags within our main Occupy-related corpus become truncated, perhaps to free up some of the limited 140 characters within a tweet. For instance, users of #occupyoakland would eventually take up #oo as their main hashtag. If you re studying #yourconference2012, the tag may change to #yourconf12. These mutations may also cause unintended consequences for your dataset -- for instance, who knew that #oo bears relevance to tweets made in Portuguese? In our case, we ve got a lot of noise to sort through, leading us to issues of validity and noise. Precision and recall. You can t collect all of the tweets related to a topic or community. You can t collect only those tweets related to a topic or community. And even given these two sources of errors, you don t want to delete Tweets. For instance, consider the following hypothetical tweet: Where did all of these hippies in the Financial District come from? This tweet is almost certainly related to Occupy Wall Street, but none of the words in the text could feasibly be used given our previous keyterm guidelines. So if we were to say we ve collected every tweet about Occupy, we d certainly be incorrect, as would anyone who makes such a HICSS Workshop 2013 Research in Social Media SoMeLab.net page 8

9 claim. Likewise, your keyterm selection will also almost always contain some noise unless you ve been extremely conservative in your selection. Consider the #oo example above. Removing #oo would entirely eliminate the later more popular Occupy Oakland hashtag. Removing tweets according to language would remove Portuguese speakers actually concerned about Occupy Oakland or events happening there, including local and international speakers. Don t concern yourself too much about noise at the outset! for instance, we captured protest activity in Nigeria termed Occupy Nigeria but having arguably little relation to OWS in terms of types of protest activity, goals, causality, or actors. So don t delete Tweets from your database. You can t re-obtain them after they re gone, and you ruin the validity gained by having every Tweet that matches your keyterm set. You can always query out Tweets that don t match your current research objectives, or create separate databases for those that do. 5.2: Terms of service One of the unfortunate hurdles social media researchers face is how to deal with the myriad terms of service (ToS) associated with each platform, at both the level of the user as well as the level of the developer or person accessing the API. We recommend finding the pages related to these terms of service at each of these labels, and setting up an alert for when these pages change, as they can often do so without warning. There is little uniformity to these across platforms, which may mean some platforms are more open to research possibilities than others. For Twitter, the most relevant ToS involve what you can do with the data that you collect. At the time of this writing (an extremely important boundary here), the most relevant rule is that you can t share raw data with another party unless you pay Twitter s licensing fees or are directly in collaboration with another researcher. It isn t terribly clear what that last phrase means, but to our knowledge the most stringent action taken against a researcher has been delivery of a cease & desist notice. You are permitted to share aggregated data that has been stripped of identifying features as noted in their ToS. Because the purpose of the SoMe Lab Toolkit is to provide an opening for you to avoid paying third-party vendors of licensed Tweets, if you use this toolset, you ll be collecting the data yourself. This also allows you access to all of the raw data through your own means. This does mean that you re bound by Twitter s ToS regardless of which toolset you use, including our own. So be extremely cautious in sharing the data you collect. 5. Ethics We believe that social media researchers have a special ethical obligation to consider the risks and potential impacts of their research. We have observed that the boards within institutions originally tasked with evaluating risks to human participants over the past decades have become increasingly concerned with the protection of the research institution itself, with an aim of avoiding legal entanglement associated with research and research findings. The local policies and practices vary considerably, but our experiences at universities with medical schools suggest that the local institutional review boards (IRBs) are better equipped to deal with biological and medical research issues than with social science research. Because you often can make the case for social media data as public, it s possible that you won t have much trouble from your own IRB. This section is intended to help move you beyond what s good enough for IRB human subjects review and into a mode of research that treats subjects ethically and responsibly. To that end, we ll review what it might mean to be public with regard to social media use both from IRB s perspective and the perspectives gleaned from HICSS Workshop 2013 Research in Social Media SoMeLab.net page 9

10 ethnographic work with social media users. We ll then turn to a discussion of risk with regard to the subjects of social media research, focusing on ramifications largely gleaned from our panel discussion at the Internet Research 13 (IR13) conference. We d also like to point you to the Association of Internet Researchers document dealing with the ethics of internet research as a more robust piece that addresses items we re unable to note due to space and time constraints. You can find that document at this address: Public is an increasingly bizarre concept in today s rich information ecosystem, and the notion of whether or not certain activities are public is a main point of contention in a human subjects review. The truth is, thanks to the ToS for most social media platforms, the content within these platforms is deemed publically available, both legally and in regards to a human subject review. This means that you re unlikely to face resistance toward your research project if you stick to public streams. However, this doesn t necessarily mean that users intend for their actions to be public. For instance, you may have picked your nose in a public space at some point in your life. We d suspect that you d rather not be photographed picking your nose and then see that photograph on the front page of Reddit. Sometimes public actions aren t intended for public consumption. As danah boyd and Kate Crawford discuss in their 2011 paper, 1 the explosion of interest in Big Data presents challenges for researchers looking at the traces people leave as they interact with artifacts, systems, and other people. They point out issues associated not only with data collection but also with the research methods used. Helen Nissenbaum s work (2010) 2 considers the fundamental issue of privacy from a privacy in context perspective, looking at the reasonable expectations individuals and groups may have about their social behavior being observed (or recorded) in different settings. Taking this viewpoint, researchers might place themselves in the position of those being observed and ask what they would like to have reported about their behavior. In spite of the terms of service and legal protections available, users often don t think of the data they produce as being open to public consumption. While this legal gray area is profitable for social media companies, we feel that researchers should give more attention to the ethical dimensions of our work. One useful framework for evaluating your ethical obligations as a researcher is a consideration of risk to the subjects whom you study. Carefully evaluating the visibility of subjects within your research reports is tremendously important with social media, as many social media platforms are archived, catalogued, and searchable through a variety of different engines. With that in mind, you might consider using pseudonyms for users instead of their actual user accounts in reports. This might not be an issue for public figures (e.g., George Takei), but it should certainly be taken into consideration for those who don t fit that metric. Likewise, directly quoting the text of tweets allows the text to be tied to a user account regardless of whether or not you use a pseudonym. Search engines may only allow for a limited number of days retrievable through a social media platform, but folks with unfettered access to the platform can also likewise match the user to the tweet. Keep in mind that 1 boyd, danah and Crawford, Kate, Six Provocations for Big Data (September 21, 2011). A Decade in Internet Time: Symposium on the Dynamics of the Internet and Society, September Available at SSRN: or 2 Nissenbaum, Helen Fay Privacy in context : technology, policy, and the integrity of social life. Stanford, Calif.: Stanford Law Books. HICSS Workshop 2013 Research in Social Media SoMeLab.net page 10

11 unfettered access often also means historical access, which means platforms, state-interests, and market elite can all match your research report to the users in question. Does this put your users at risk? It depends entirely on your research. You should also think about the security of your data, both in terms of technical security and legal security. In terms of technical security, you ll want to ensure that all of your data are encrypted, particularly if your subjects may be at risk from your research. Amazon Web Services do this extremely well with little intervention on your part. But once your data leave an encrypted environment, have a plan to protect the data which might include encrypted file folders with password protection, perhaps on media that you can lock in a filing cabinet. Likewise, don t keep your data in unsecured locations, such as a cloud based service like Dropbox. In terms of legal security, if you are part of a state-funded school or receive federal funding for your research, your work may be subject to a Freedom of Information Act request. To this end, we highly recommend using non-university associated accounts to discuss research. And never send your data across accounts. And as with all work involving human subjects, you may find yourself in morally compromising situations involving the law. You may uncover illegal activity through the collection of your tweets. Likewise, law enforcement officials may also request your data, as they ve subpoenaed Twitter for some of the tweets related to Occupy activities. You ll ideally want to have a plan in place for each of these instances before they come to pass, particularly in relation to what your institutional policies regarding the independence of researchers. 6. Conclusion Social media research is challenging. As an emerging field, current social media work presents even experienced researchers with some of the most interesting and exciting yet some of the most perplexing socio-technical opportunities we can imagine. If our experience in the SoMe Lab is typical, researchers going into this emerging field find themselves diving deeper into technical issues and socio-ethical questions than they initially expect. Our work has required developing new technical skill sets and gaining experience with a dynamic and sometimes bewildering set of rules and terms of service. We see the need for all of us working in the field to share experiences and research tools and to develop a shared set of expectations for reporting our findings. Although each project may be unique and require multiple decisions, we see the value in finding efficient ways to make these decisions transparent (through standards or other frameworks), as the details of these decisions can significantly affect the research outcomes. Our open source SoMe Lab toolkit can be one part of a foundation for sharing work, lowering the technical barriers to social media research. However, it can only be the beginning of what we see as what can be a broad-based community of researchers who share what we are learning about how to improve our approaches. At our HICSS workshop, we ll be seeking ways to maintain such a learning community. HICSS Workshop 2013 Research in Social Media SoMeLab.net page 11