Peter Scott (eds.): Proceedings of the 2nd International Workshop on Research 2.0. At the 5th European Conference on Technology Enhanced Learning: Sustaining TEL. Barcelona, Spain, September 28, 2010, CEUR-WS.org/Vol675, ISSN 1613-0073. c 2010 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. Re-publication of material from this volume requires permission by the copyright owners.
In recent years, Web 2.0 has become manifest in new types of applications causing fundamentally new experiences of large-scale social interaction. It has affected the way people communicate, share, collaborate, and - ultimately - participate on the Web. The technologies associated with ”the Web 2.0” have a focus on broadened participation by lowering the technical barriers for users. Over the years, the ability to publish content on the Web with little technical knowledge has created not only a new level of public accessible data, but also created the dynamic world of the social Web. The openness of the Web also allowed building new services based on old ones, fostering the development of a mash-up culture.
savvy areas of research. However, what does this really mean? Is it about the adoption of existing tools and services? Is it about the (re-)development of applications based on success criteria of Web 2.0 applications? Is it about the distillation of good practice and their diffusion amongst researchers, either bottom-up or top-down? What type of methodology is appropriate to investigate Research 2.0 phenomena?
The first area is concerned with availability of data. Access to sanitized data and conventions on how to describe publication-related meta-data provided from divergent sources are enablers for researchers to develop new views on their publications and their research area. Additional, social media data gain more and more attention. Reaching a widespread agreement about this for the field of technology-enhanced learning would be already a major step, but it is also important to focus on the next steps: what are success-critical added values driving uptake in the research community as a whole? The second area of challenges is seen in Research 2.0 practices. As technology-enhanced learning is a multi-disciplinary field, practices developed in one area could be valuable for others. To extract the essence of successful multi-disciplinary Research 2.0 practice though, multi-dimensional and longitudinal empirical work is needed. It is also an open question, if we should support practice by fostering the usage of existing tools or the development of new tools, which follow Research 2.0 principles. What makes a practice sustainable? What are the driving factors?
other research artefacts) published on the Web? How can this be related to the publishing world appearing in print? Is a link equal to a citation or a download equal to a subscription?
questions of authority, quality and re-evaluation of quality, and trust.
emphasis (a) on tools, applications, and infrastructure components supporting researchers and (b) on insights into how practices of researchers change. It combined quantitative and qualitative approaches shedding light on different facets of Research 2.0.
change publication meta-data. They propose to use a semantically enriched RSS format, which allows institutions to exchange publication meta-data and to make this meta-data accessible for research. The paper also presents complementing services and widgets, and outlines the benefit of the approach for institutions.
searcher” a mobile application called More! that serves the discovery of researcher profile information about a speaker at a conference. Their approach takes into account the various identities of researchers on the Web to present relevant information for researchers with a unified interface. The mobile application presents information about the researcher, the current work, and social handles.
vision and strategy for the STELLAR network of excellence. In their paper ”Research 2.0:
experiences with a wiki software in the collaborative writing process. They discuss risks and outline strategies to overcome them. They especially highlight the importance of the engagement of the contributors, the discussion features of wikis, and the clarification of the overall goal of the collaboration.
per ”Research at the Table”. They focus on the support of researchers in finding scientific papers. Researchers can explore the co-author space of publications. Two tasks are supported. Researchers can either use the multi-touch table to explore the publication world top-down or they can use the table with a bottom-up approach, exploring the neighbourhood of authors.
Despotakis, Brandic, and Dimitrova presents tools of the JISC Brain (Building Research and Innovation Networks) project with emphasis on identifying connections between researchers, as well as researchers and business and other wider partners. The tools described in the paper provide facilities for researchers to search for other researchers by keywords, which are related to own work, and to find links between researchers. Central to their work is a Research 2.0 approach supporting researchers in several stages of their research carrier.
network of excellence in their paper ”The Afterlife of ”Living Deliverables”: Angles or Zombies”. It focuses on collaboratively authored online project reports, that use a wiki software to support the writing, but also serve to enable knowledge exchange after the submission deadline. While wikis tend not to emphasize authorship of individuals, versioning history data of the wikis allow drawing conclusions on the nature of the collaboration and particularly on which authors collaborated on text passages and topics. In their empirical investigation, they describe the collaboration on a deliverable before and after the deadline. They state that most of the deliverables are used also after the deadline, while others only exist for the purpose of writing up and delivering.
to Export, Archive and Search your Tweets” by the authors Muehlburger, Ebner, and
after an event, they propose a solution in the form of an application called Grabeeter, which stores the tweets locally, allowing analysing the tweets also after the event. They discuss the architecture of the application client and server aspects and they focus specifically on how to use the system for conducting research.
didates in TELWorking with Web 2.0” from Heinze, Joubert, and Gillet, reports on a case study about the needs of young TEL researchers. The authors asked 21 doctoral candidates and three senior researchers about how they would wish to receive support for their doctoral work: regarding personal support, awareness support, and tools for collaboration.
Peter Kraker, Angela Fessl, Patrick Hoefler and Stefanie Lindstaedt
Gonzalo Parra and Erik Duval
Marie Joubert and Rosamund Sutherland
Bram Vandeputte and Erik Duval
Till Nagel and Erik Duval
Jim Hensman, Dimoklis Despotakis, Ajdin Brandic and Vania Dimitrova
Fridolin Wild and Thomas D. Ullmann @twitter Try out #Grabeeter to Export, Archive and Search Your Tweets
Herbert Muehlburger, Martin Ebner and Behnam Taraghi
Nina Heinze, Marie Joubert and Denis Gillet 8 18 24 38 48 54 66 76 86
Feeding TEL: Building an Ecosystem Around BuRST
to Convey Publication Metadata Peter Kraker1, Angela Fessl1, Patrick Hoefler1 and Stefanie Lindstaedt1 1 Know-Center Graz, Inffeldgasse 21a,
8010 Graz, Austria {pkraker, afessl, phoefler, slind}@know-center.at Abstract. In this paper we present an ecosystem for the lightweight exchange of publication metadata based on the principles of Web 2.0. At the heart of this ecosystem, semantically enriched RSS feeds are used for dissemination. These feeds are complemented by services for creation and aggregation, as well as widgets for retrieval and visualization of publication metadata. In two scenarios, we show how these publication feeds can benefit institutions, researchers, and the TEL community. We then present the formats, services, and widgets developed for the bootstrapping of the ecosystem. We conclude with an outline of the integration of publication feeds with the STELLAR Network of Excellence1 and an outlook on future developments. 1
Introduction
Recently, developments under the paradigm of Science 2.0 have received a lot of
attention [
In this paper we present an ecosystem for the exchange of publication data based
on existing Web 2.0 infrastructure. At the heart of this ecosystem, semantically
enriched feeds based on the popular RSS format [
To facilitate the opening of institutional archives, easy-to-use tools are needed.
Web services are especially apt for this, since they are the cornerstone of Web 2.0,
allowing for loosely coupled systems and simple syndication [
This paper consists of three sections. At first, we introduce two scenarios for the usage of publication feeds in research from a personal and an organizational perspective. Then, we present the pillars of the ecosystem, namely the adapted BuRST format, a suite of web services for feed producers, and several widgets for feed consumers. Finally, we conclude with an overview of the integration of the ecosystem into the STELLAR Network of Excellence and an outlook on future developments. 2
Scenario
In the following section we present two scenarios which illustrate the benefits of the presented ecosystem. These scenarios emphasize on lightweight dissemination, visualization, and navigation of semantically-enriched scientific publication feeds in the style of Web 2.0. 2.1
Scenario 1: Semi-automated dissemination of publication feeds
Sandra is a supervisor at a TEL research institution dedicated to professional learning. She is responsible for collecting the publications of her group. Therefore, her assistants keep a BibTeX file of their publication metadata, which is periodically uploaded to a common server. Sandra is interested in a wider dissemination of this data, but unfortunately she cannot get her assistants to enter the publication data over and over again into other repositories. Hence, she is looking for a way to automate dissemination. Since publication data is already available in several BibTex files, she uses a dedicated BibTeX converter to convert these files into publication feeds. The resulting individual feeds are then merged into a single feed with the help of the Publication Feed Merger. Due to the fact that there are also publications not related to TEL in the feed, a Publication Feed Filter is applied. Sandra now publishes this feed so that all interested parties that support the BuRST format can subscribe to it. 2.2
Scenario 2: Explorative research on publication feeds
Kurt is an early-career researcher interested in professional learning. He wants to find out about the most influential publications, recently trending topics, and interesting conferences in the field. Therefore, he joins a special interest group dedicated to professional learning on a social networking platform. Sandra and other users have already added their institutions' publication feeds to this group. The individual publications are presented as blog posts, which can be rated and commented on. Kurt now has an overview of the top rated publications and the discussions revolving around them.
Kurt then opens the "Publication Visualization" widget from within the special interest group. He is presented with a faceted browsing view containing all publication metadata from the feeds. A tag cloud aggregated from the keywords is additionally shown to Kurt. He then restricts the data to certain years to see the changes in the tag cloud. This allows him to reflect on the trending topics.
Next, Kurt restricts the publication type to conference proceedings. Now, all proceedings titles are presented to him, alongside the corresponding articles. From the keyword tag cloud, he chooses a topic that he finds interesting. This supplies Kurt with a list of conferences that are important for that specific topic. 3
Publication Feed Ecosystem In this section, we present the three initial pillars of the publication feed ecosystem: the adapted BuRST format, a suite of web services for feed producers, and several widgets for feed consumers. 3.1
Publication Feeds
Publication feeds are RSS 1.0 feeds, enhanced with elements from the SWRC2 and
DC3 ontologies. These feeds are an adaption of the BuRST4 format, proposed by Peter
Mika [
See below for an exemplified item representation. The item is divided into two parts: 1. A native RSS part 2. A RDF extension part (highlighted in grey)
Both parts are linked through the burst:publication property. Information given in the RSS part of the item is mainly intended for display purposes (e.g. in RSS feed readers or widgets), and for processing in other tools which can deal with RSS (e.g. Yahoo! Pipes). The RDF extension part describes the publication in a semantically much more sophisticated way. This part is intended for tools and services that are able to process and display BuRST feeds (see sections 3.2 and 3.3), as well as semantic web applications that understand RDF.
Example of a publication represented in a BuRST feed.
The publication feed format serves two purposes: firstly, it can be understood by existing Web 2.0 infrastructure, which is capable of processing and visualizing RSS feeds. Secondly, it has the expressive power of RDF to describe publication metadata and to link entities through URIs. The example given contains a minimum set of attributes, especially addressing the "what?", "who?", "where?", and "when?". The available vocabulary is much larger, because the whole SWRC ontology can be used to markup publication metadata. 3.2
Publisher Services
The Publication Feed Publisher Services are a suite of helper services aiding
individuals as well as institutions in producing, aggregating, and refining publication
feeds. Services are one of the cornerstones of Web 2.0, allowing for loosely coupled
systems and simple syndication [
All publisher services were written in PHP. They are free for everyone to use, and there is no registration or API key required. To help with the orchestration of these services, a DERI Pipes [13] Installation is available at [14], along with a frontend to the BibTex converter [15]. 3.3
Subscriber Widgets
The Publication Feed Subscriber Widgets are a suite of widgets for the visualization of and the interaction with publication feeds. They were designed according to the needs of researchers described in scenario 2. Specifically there are two widgets already implemented: 1. The Publication Feed Integration Widget was designed as a plugin to the social networking platform system Elgg [16]. It is based on Blogextend [17] and the Simplepie RSS Feed Integrator [18]. The widget allows members of an Elgg platform adding publication feeds to groups. The publications contained in these feeds can be accessed via a common group blog. As pictured in Figure 1, individual publications are being visualized as blog post entries. Users are able to rate each publication and engage in discussions with each other by posting comments. 2. The Publication Feed Visualization Widget is available as a native Elgg widget and in a Wookie [19] version. It visualizes publication feed items in a faceted browser view based on Simile [20]. The faceted browser currently allows for filtering the publication feeds along the dimensions authors, publication years, and keywords, but this could easily be expanded to include other fields contained in the feeds. The filtering mechanisms are complemented with a full text search. Furthermore, a timeline visualization orders publications chronologically and allows users to intuitively browse through them. A tag cloud helps with detecting the most important keywords for a given collection of publications.
Integration into the STELLAR Network of Excellence
The publication feed ecosystem is being integrated with the STELLAR Network of Excellence. See Figure 2 for an overview of the proposed concept.
As a first step, all partners within STELLAR are asked to produce a publication feed. In the process, they are able to use the publisher services described in section 3.2 to generate their feeds. The published feeds are in turn being used to update the STELLAR Open Archive (SOA) [21], an open access platform dedicated to collecting and distributing TEL-related publications as well as the accompanying metadata. Therefore, the SOA subscribes to all of the feeds generated by the partners. The SOA is not only an archive, but it also acts as an aggregator of feeds, allowing to export all or parts of the collected publications as publication feeds. As shown in Figure 2, other tools, which are able to process RSS (such as feed readers) are able to subscribe to the publication feeds as well.
At the same time, the subscriber widgets described in section 3.3 are being deployed to TEL Europe. TEL Europe [22] is a social networking platform based on Elgg for all stakeholders in Technology Enhanced Learning in Europe, operated by STELLAR. With these widgets, users on TEL Europe are able to add relevant publications to a group in subscribing to any publication feed. The feeds might be coming from the SOA, from individual partner institutions, or indeed from any publisher of such a feed (e.g. a special interest group). The members of the group are then able to start a discussion around particular publications, and they may also add a rating. Additionally, they can visualize all feeds available on the platform for search, exploration, and trend scouting.
Conclusion and Outlook
In this paper, we presented an ecosystem for the lightweight exchange of publication metadata contributing to the prerequisites for a modern Science 2.0. In two scenarios, we showed how publication feeds can benefit researchers, institutions, and the TEL community. We described the main building blocks of the ecosystem, being (1) the feed format, (2) publisher services, and (3) subscriber widgets. Lastly, we outlined the adoption of the ecosystem by the STELLAR Network of Excellence.
The adoption process has not been finished yet, but the first results are promising. Four partners in STELLAR are actively developing BuRST feeds. Some of them have already been submitted to the STELLAR Open Archive which recently experienced a boost in the number of publications to 10386. The two subscriber widgets have been deployed to TEL Europe and the first special interest groups are starting to use them.
There are certain challenges regarding the publication feed format, which have not been explicitly addressed in the first version. First, the vocabulary of SWRC could be enhanced to include more metadata, e.g. the Digital Object Identifier (DOI) of a publication. Secondly, URIs for authors and institutions would help to manage the entities in the network, and to detect duplicates. URI assignment can either be carried out by the individual institutions or a central repository. With a central repository there is no need to match corresponding entities from various sources, but it also imposes the burden of creating and maintaining said repository.
There are some possible enhancements concerning the existing services and widgets as well. For the Publication Feed Merger, it would make sense to implement a more sophisticated conflict management. This could be done by taking into account the richness of the metadata, as well as the source of information. In the Publication Feed Visualization Widget, additional fields will be added to the existing facets. Furthermore, there is no possibility for end users to correct errors in feed entries. This functionality, however, would rather have to be implemented with a large aggregator of feeds, such as the SOA.
Generally, harvesting and processing of RSS is an open issue. RSS feeds need to be fully retrieved under most circumstances; one is not able to restrict the data to just the new/updated items like in dedicated harvesting protocols, such as OAI-PMH7. To overcome this deficiency, we are investigating the integration of the PubSubHubbub protocol [23] into the ecosystem. In the PubSubHubbub protocol, each publisher declares a hub. Subscribers register with that hub, which in turn notifies the subscribers of new and updated items. This avoids repeated polling of the publisher’s feed and relieves the subscriber from retrieving the whole feed on update.
Due to its decentralized architecture, the publication feed ecosystem can be extended by anyone. In the future, we expect to see other interested parties contributing their own components. This openness helps making the ecosystem adaptable by other research communities and is a precondition for its sustainable future. 6 On 24/06/2010 7 Open Archives Initiative - Protocol for Metadata Harvesting
Acknowledgement
This work was carried out as part of the STELLAR Network of Excellence, which is funded by the European Commission (grant agreement no. 231913). This contribution is partly funded by the Know-Center, which is funded within the Austrian COMET program – Competence Centers for Excellent Technologies – under the auspices of the Austrian Federal Ministry of Transport, Innovation and Technology, the Austrian Federal Ministry of Economy, Family and Youth, and the State of Styria. COMET is managed by the Austrian Research Promotion Agency FFG. 7
Gonzalo Parra1, Erik Duval1 1 Dept. Computerwetenschappen, Katholieke Universiteit Leuven, Celestijnenlaan 200A, 3001 Heverlee, Belgium {gonzalo.parra, erik.duval}@cs.kuleuven.be Abstract. As one of its main goals, the Research 2.0 concept focuses on the improvement of the connection and collaboration between researchers. Within this short paper we present More!, a mobile social discovery tool for researchers. We describe the application itself and present some initial results obtained by using the tool on small scenarios. Later we describe the current challenges of the tool and the future developments. Finally, we state open problems of the field and the application itself.
Keywords: research2.0, web2.0, human computer interaction, mobile devices. 1 Introduction
Research 2.0 is the result of applying Web2.0 tools and approaches on regular
research processes in order to improve practices and increase participation and
collaboration [
Due to the availability and heavy use of many Web 2.0 and Research 2.0 platforms, the users have to deal with the problem of keeping and sharing with others several electronic identities [9]. This digital identity problem is also observed in the scenario where a researcher is attending a conference presentation and is interested in finding more information about the topic and the speaker. We have addressed this need and bootstrap collaboration between researchers through a mobile application, called “More!” [10].
The structure of this short paper is as follows: we first present the implemented application and its current outcomes and limits. In the following sections, the proposed solutions to two different limitations are discussed. Later, we present the open problems and opportunities for further work. Finally, we include some initial conclusions of this work in progress. 2 The More! Application
More! is a mobile web application that groups relevant information about a speaker in a way that can be easily exposed and integrated in the normal workflow of the audience of an academic event. The application exposes the following information from the speaker: • researcher: full name, photo, e-mail and affiliation; • work: current paper, slides, and publications list; • social tools handles from: Twitter, SlideShare, blog, Delicious, LinkedIn, and Facebook.
In this way, the attendee can access some regular information about the speaker; as well as the paper and slides of the current presentation; and his previous publications. Moreover, he can ‘identify’ and ‘follow’ the speaker on some of the more mainstream Web 2.0 social tools, to get access to previous, current and future work. The workflow of the application in a conference scenario is as follows: 1. The speaker exposes a QR code [11] (resolvable to an URL link) to the audience. 2. Attendants capture and decode the QR code by using any code reader application available on their smart phones. After decoding, they are redirected to the “More!” web application. 3. “More!” presents the data on the client tool.
After evaluating the usability and the functionality of the tool in a real life scenario, we noticed two big limitations in this workflow [10]. The first limitation is related to the metadata needed to feed the tool. The More! application requires research and social tools metadata, and relies heavily on the availability of such data. The problem encountered was related on how to obtain this metadata.
The second problem encountered is related to: how the QR code is exposed to the audience, the extra work required by the speaker to make the codes visible to the audience, and the poor image quality of photos for the QR decoding applications on mobile devices.
Finally, the backend and the frontend of the More! application required different approaches to efficiently solve the original problem for which the application was made. 3 Improving the Back-end: Research.fm
As presented in the previous section, we identified the need to have a common entry point and a unified metadata sharing approach to feed the application. Currently, More! is using a local database where this data is stored, but this approach is neither scalable nor aligned with the Research2.0 concept of open data. For this reason an initial approach is being developed to expose and share research metadata: the research.fm API.
The research.fm is a RESTful API that will give access to social networks and publications data of scientific authors in a standardized way. This service exposes common data requirements for applications by following the Cool URI approach in order to provide readable, logic and persistent endpoints. On the other hand, the be extended by adding pages as nodes to the network and introducing directed editing relationships pointing from the authors to the pages they have changed. With that, authoring relations on particular pages become more salient.
Additionally, the development of the overall number of non-minor edits over time provides information on the vitality of the wiki and complements the analysis. 5 Discussion: Is there an afterlife after the deadline?
The deadline of regular deliverables marks the end of the writing process. After the deadline, the official writing process ends and there is no formal requirement to modify them anymore. As mentioned above, the purpose of living deliverables is to allow for more continuous collaboration beyond delivery deadlines. The assumption behind living documents is that knowledge construction processes are continuous and deliverables are artefacts of an underlying, continuous collaboration process. By turning these artefacts into living documents, they better reflect the dynamic structure of project work, which is somewhat artificially subjected to a project framework in order to allow for efficient and effective management. Not only in networks of excellence, where a consortium faces additionally the challenge to re-organise an open research network beyond the partnership, but also in other research project types, interdependencies of tasks naturally create feedback loops that should inform already ‘delivered’ work (such as from validation to conceptual design), thus creating an opportunity to update them.
To test whether or not the documents were subject to editing activity also after the submission deadline, we gathered the revisions of each deliverable and cumulated the amount of revisions for each deliverable for each project month. The following line chart shows on the y-axis the amount of revisions and on the x-axis the time frames (16 project months). One deliverable already exists since 13 months, while others are in use for shorter periods of time. The vertical lines at month 3, 6, 9, and 12 represent the submission deadlines.
All deliverables continue their life also after their formal deadline. Even when considering a phase of two months after the deadlines (taking into account possible delays in delivery), still three of the deliverables show lively activity. According to the revision counts, the official deadline raised the number of revisions, while after a deadline the amount of revisions increases mostly less steep. The three deliverables d6.2 (blue), d6.3 (purple), and d1.2 (yellow) show a very steady increase over time, whereas particularly the early deliverables d7.1 (orange) and d1.1 (green) experience their most busy editing processes around the time of their deadline.
While the line chart visualisation only shows the frequencies of the revisions over time, it does not provide information about the themes of collaboration and the collaboration network created in the co-editing activity – and how they have changed from before to after the deadline. 4. Home
Katrienv
Kmi!systems
Rcrespo 7.Science_prox 1.Main_Page 2.Sidebar 3.Mainpage
UlmannWiki Zeiliger 25.Wookie_Elgg 9.Soa_smal.pn 8.Open_archive
Figures Figure 5 and Figure 6 show the network of authors and their contributions to pages in d6.3 before and after the submission deadline. While the focus before the deadline is clearly on ‘use cases’, ‘scenarios’ and the main page of the deliverable, the
The other deliverables show similar patterns of activity: d7.1 again exposes a larger network of pages (but with a smaller number of contributors), where as d1.1 is significantly reduced in the number of contributors (but still showing a larger number of edits). The deliverable d6.2 shows a star pattern of authors editing the main page and d1.2 ceased its activity with its delivery deadline. 6 Conclusion and outlook
With the analysis presented, the conclusion can be drawn that there definitely is an afterlife for most of the living deliverables. With only one zombie exception, this afterlife is more like a blitheful continuation of activities – relieved of the duty of having a deadline. At least for the one deliverables we have analysed this in more depth and collaboration beyond the deadline exposes a large co-authorship network, accompanied by shift in focus.
As stated the data are extracted from the public revision histories of the living deliverables, made available by MediaWiki. They can be used to show whether wikis show any signs of editing activity and to further investigate the collaboration network structure expressed in these revisions. It is possible to inspect who is collaborating on particular pages. In large projects, like STELLAR, these visualisations can help to make activities more transparent which can create more awareness and accountability – and ultimately offers triggers for new activity.
For living deliverables as such, it provides a way to check for signs of life, especially when their delivery deadline has passed.
There are several limitations this study has. Most notably, collaboration in coauthoring wiki pages cannot be mistaken for the overall collaboration on the (printed) report delivered to the European Commission. All wikis had phases close to the deadline, where an export of the Wikipages into a Word-file served the final polishing and further elaboration. All the deliverables were embedded into collaborative activities of other nature, such as presence and virtual meetings (flashmeetings), reviews (with separate reports), and other forms of collaboration that left no traces in the wikis. Still they are part of the process of creating their content.
Moreover, we have so far looked at only a small number of living deliverables in a limited time period. It will be very interesting to see, whether our findings will be confirmed when repeated in the future with more data and a longer time frame. Not to mention that it will be interesting to see, whether there is an afterlife of the deliverables beyond the runtime of the project.
It is an open question, whether the analysis method used can be matured into a selfexplaining visualisation that does not require any insider knowledge about the collaboration in order to correctly read it. Or in other words: an evaluation of usability and accuracy is pending. This might also be helpful further what (wiki-wise) the difference between a living and living dead deliverable is. And it might help to identify driving factors: is it the medium, the collaborators, or the content?
In its current form, the co-editing network plots depict only a holistic view of all contributions. A more flexible approach would be to let the user interactively choose time windows, thereby providing means to investigate collaboration patterns before and after significant events. An animation of the graph change over time would additionally help to understand the development of a living deliverable, emphasizing the process dimension further.
A more fine-grain distinction of the types of contributions and their drivers would serve further analysis: writing passages, proofreading, enhancing with links and media, discussing, altering, and deleting text are all important for the quality of an article, but possibly not all of them trigger further activity by collaborators. This would be equally interesting for life and afterlife of the deliverables.
Additional evidence sources are available to further investigate collaboration among the researchers outside the living deliverable. It would be very interesting to see whether collaboration patterns differ when looking at the accompanying virtual meetings, e-mail exchange, or presence meetings. Does the medium foster certain styles of collaborations or do they converge?
From a project oriented view the proposed type of analysis could serve as a feedback mechanism making achievements visible. This could help to activate discussion about research collaboration.
Acknowledgment
The work presented in this paper was carried out as part of the STELLAR network of excellence, which is funded by the European Commission under the grant agreement number 231913.
Herbert Mühlburger1, Martin Ebner1, Behnam Taraghi1, 1 Graz University of Technology, Social Learning, Steyrergasse 30/I,
8010 Graz, Austria
{muehlburger, martin.ebner, b.taraghi}@tugraz.at
Abstract: The microblogging platform Twitter is beside Facebook the fastest
growing social networking application of the last years. It is used in different
ways, e.g. to enhance events (conferences) by sending updates, hyperlinks or
other data as a news-stream to a broader public. Until now the stream ends with
the end of the event. In this publication a new application is introduced that
allows information retrieval and knowledge discovery by searching through
local stored tweets related to a corresponding event. The architecture of the
prototype is described as well as how the data is being accessed by a web
application and a local client. It can be stated that making tweets available after
the end of an event, enhances the way we deal with information in future.
1 Introduction
Twitter1 and Facebook2 are the fastest growing platforms of the last 12 months3 [12].
On 22nd of February 2010 Twitter hits 50 million tweets per day4. Without any
exaggeration it can be said that these two social networks are worth to be researched
in detail [10] and are of interest for scientists and educators. After a period of testing
first results emerge on this form of communication and interaction in science [
Taking a look at the usage of Twitter at conferences we notice the increase of
reports, statements, announcements as well as fast conversation between participants.
So called Twitter-walls nearby the projection of an ongoing presentation [
One of the most recent studies on using Twitter at Web 2.0 conferences [
Basically there are two core issues - Twitter should be used first for communication between participants instantly and second for documentation on their own. Especially in case of documentation this will be only useful if users are able to create a kind of archive where they can store their tweets.
This publication deals with the research question, what can be the advantages of a web-based application that can also be used offline (without Internet connection) for information retrieval and knowledge discovery based on a micro-content system like Twitter.
“Grabeeter – Grab and Search Your Tweets” is the name of the application that has been developed in order to fulfil these requirements. The next chapter describes Grabeeter in more detail by giving an overview of the system’s architecture and its particular features. 2 Architecture of Grabeeter The architecture of Grabeeter (see Fig. 1) consists of two main parts. The first part is a web application that retrieves tweets and user information from Twitter through the Twitter API5. The second part of Grabeeter consists of a client application developed in “JavaFX6 technology for accessing the stored information on a client side.
Fig. 1. Architecture of Grabeeter
As illustrated in Fig. 1 the Grabeeter web application implements the Twitter API in order to retrieve tweets of predefined users. The tweets are then stored in the Grabeeter database and on the file system as Apache Lucene7 index. In order to ensure an efficient search the tweets must be indexed. The Grabeeter web application provides access to the Grabeeter database through its own REST style [8] API. This enables client applications to retrieve tweets and user information in an easy way by implementing this API. In difference to the Twitter API Grabeeter API provides all stored tweets and makes no restriction over time.
The Grabeeter client application is developed using JavaFX in order to be independent from different operating systems as well as to provide an easy process to 5 http://apiwiki.twitter.com/ (last access: 2010-04-21) 6 http://www.sun.com/software/javafx/ (last access: 2010-04-16) 7 http://lucene.apache.org/java/docs/ (last access: 2010-04-21) upgrade the client application using Java Web Start8. Furthermore it provides an easy way to store the retrieved tweets on the user’s local file system for later offline processing. The following sections describe the different parts of Grabeeter in detail. 2.1 The Grabeeter web application enables users to archive their tweets in the Grabeeter database and to perform a search on the stored tweets through a web interface. The tweets are not only stored in the database but also indexed by Apache Lucene in order to support an efficient search on the tweets. These tweets can be accessed then by client applications through the Grabeeter REST style API9.
As illustrated in Fig. 2 users are able to carry out a search on the stored tweets online or launch the Grabeeter JavaFX Client application by pushing the “Launch” button and search their tweets using the client application.
The workflow of the Grabeeter web application is as follows: At first users register their Twitter usernames at the Grabeeter web application. These usernames are stored in a text file which is parsed later by a cron job. The cron job runs a PHP script that retrieves all accessible tweets for the given usernames. Later another cron job updates the tweets for all monitored users on a scheduled timetable. 8 http://java.sun.com/javase/6/docs/technotes/guides/javaws/index.html (last access: 2010-0421) 9 http://grabeeter.tugraz.at/developers
Fig. 2. Grabeeter Web Application
Due to Twitter’s REST API Limit10 it is only possible to access the latest 3200 tweets (statuses) via the API of a given user on Twitter. So in case a user has less than 3200 tweets on Twitter at the time of registration on Grabeeter all of the user’s tweets are archived. From that time on all future tweets are stored and the entire first (3200 or less) tweets remain accessible and searchable too. In that way all tweets of a user ever become saved and searchable. If a user has more than 3200 tweets on Twitter at the time of registration on Grabeeter it is only possible to retrieve the latest 3200 tweets of this user from Twitter due to the Twitter limit. But from that time on all of the future tweets are archived and searchable through Grabeeter.
Later processing of the stored tweets enables us to achieve more enriched data sets by adding different kind of metadata to the stored information. However this step is not yet implemented and is described in more detail in section 4 regarding future work. 10 http://apiwiki.twitter.com/Things-Every-Developer-Should
Know#6Therearepaginationlimits (last access: 2010-04-21) 2.2
Grabeeter Client Application The Grabeeter client application was developed using JavaFX technology. It was tested on different operating systems such as Windows XP, Ubuntu Linux 10.04 and MacOS X running the latest Java SE Runtime Environment.
In order to start the Grabeeter Client application the user clicks the “Launch” button provided on the Grabeeter website (see Fig. 2). While the application starts a shortcut is created on the user’s local desktop. Through this shortcut the user is able to restart the application later on instead of using a browser.
The user provides a Twitter username to the client (see Fig. 3) and starts the grabbing of tweets by clicking the button “Grab Tweets”. In order to initially grab its tweets the user has to have an internet connection. The Grabeeter Client application then connects to the Grabeeter Database through the Grabeeter API in order to retrieve the tweets. The retrieved tweets are then stored on the local file system in a structured XML format. This enables other applications to access the locally stored tweets for their own purposes.
The Grabeeter application then loads the locally stored tweets and creates an in memory Apache Lucene index. Users are then able to perform a full text search and filter their tweets by specifying a time period.
Initially the Grabeeter Client application works in online mode in order to retrieve and store the entire recent tweets using the Grabeeter API. After restarting the application the locally stored tweets are loaded and indexed again. Therefore users are able to perform searches on tweets without having internet connection and so being independent from web services. 3 Discussion The following lists interesting aspects that occurred during the development of Grabeeter using JavaFX and the Twitter API.
„Drag-To-Install“: One very utile feature of JavaFX is the „Drag-To-Install“ possibility. It is the ability for an application to be dragged-out of the browser window and being “installed” on the operating system by dropping it onto the operating system’s desktop. The term “installed” means here that a shortcut is created on the desktop and that the JavaFX application is added to the Java application cache on the corresponding operating system. This feature seems not to function properly on MacOS systems so far. From this point of view a new version of the client can be updated in the background without knowledge of the user.
Twitter API restrictions: As already mentioned Twitter REST API requests are restricted to the latest 3200 tweets of a user. There is no chance for any application to access the first tweets, in case the user has already more than 3200 tweets.
Twitter capacity problem: Sometimes the Twitter API is over capacity. In this case no data can be retrieved from the API. This might delay the archive process in Grabeeter web application.
Beside these restrictions Grabeeter may have an interesting effect on the change of writing style: Due to the fact that the suggested tool is able to retrieve data the user is able to document his/her experiences from an event over a time period. This leads to reassess about how we have to use microblogs in general and how we have to write our tweets in order to regain relevant data. Overall this means tweets are written primarily for users themselves and not for a broader public which is a very new aspect to the basic intention of Twitter. With the help of the tool it is now possible to retrieve all tweets concerning a specific hashtag (e.g. event) within a clear defined time frame. Any collected hyperlink can be reused by searching for the specified event and clicking on the appropriate tweet.
If users register on Grabeeter before they reach 3200 tweets on Twitter it is possible to archive and retrieve all tweets from these users. For Grabeeter performs incremental updates and stores all tweets in its archive all tweets of a user are stored continuously from the beginning up to future tweets.
According to our research question in the beginning we like to point out the advantages of the tool Grabeeter: Micro-content (tweets) is achievable due to the fact that any tweet can be retrieved at anytime from a local hard-drive Micro-content is storable in a way that the user can distinguish between different events Micro-content is searchable along keywords, hashtags, time frames as well as different entities (URLs, @, … )
From a technical point of view update process is easily and independence of devices and operating systems is guaranteed. 4 Conclusion and Future Work Grabeeter was launched in May 2010. The web application as well as the JavaFX client can be accessed at http://grabeeter.tugraz.at.
The rapid improvements in the mobile technology have led to an ascending trend of using mobile applications in recent years. Consequently more users use mobile devices to access online applications. It is planned to build the Grabeeter client as a mobile application for different platforms (Android, iPhone, JavaFX devices …). The adaptations that must be performed are mainly the view adjustment and an appropriate look and feel for the mobile environments.
The next main extension of Grabeeter will be the capability not only to retrieve the search results of a simple search query to the user, but also to combine multiple search queries over multiple users for the analysis of the archived data sets, for data exploration and a better knowledge discovery. Use of semantic technologies and interlinking techniques for this purpose would definitely enrich the data sets and enhance the usefulness of stored tweets. The first step will be to describe the archived data sets semantically, to “triplify” the data sets and convert them to RDF triples by applying the existing vocabularies used for microblogging.
The tweets of each user can be extracted and analysed towards relevant keywords to get a feeling about the main topics for e.g. a specific event. The text fragments in tweets can be extracted and interlinked with resources in the Linked Open Data11 (LOD) cloud such as DBpedia, Flickr, Geo-names, etc. The Twitter users can be interlinked with FOAF profiles in the LOD cloud too. Having the data sets triplified and interlinked with LOD it will be more efficient to analyse the collected data from the Twitter API. It will become possible to perform a more accurate knowledge 11 http://richard.cyganiak.de/2007/10/lod/ (last access: 2010-04-16) discovery and retrieve search results not only within tweets gained from the Twitter API, but also in interlinked resources of the World Wide Web.
Furthermore a SPARQL12 endpoint can be provided in Grabeeter web application to let different monitoring and analysing client applications to perform SPARQL queries over semantic data sets. As an example searching for tweets containing a geographic term such as “Vienna” would return also the tweets that contain the term “Wien”, which is the German word for Vienna. Search queries can be made even much more complex: Get tweets that contain links to photos related to the place where conference xy takes place.
Get tweets that are related to informatics and semantic technologies. It can be summarized that the described application allows retrieving status updates from the most famous microblogging platform Twitter for information retrieval on a local hard drive. Furthermore through the combination of tweets from different Twitter users with predefined keywords or hashtags the knowledge discovery seems to be opened up in a new dimension. For the first time the documentation of events by just simply tweeting of statements, hyperlinks or media files becomes possible. Grabeeter is built to enhance the usefulness of microblogging on conferences and allows retrieving data that was produced just on the fly.
References 1. Bernhardt, T., Kirchner, M.: Web 2.0 meets conference – the EduCamp as a new format of participation and exchange in the world of education. In: Ebner, Martin / Schiefner, Mandy (Eds.): Looking Toward the Future of Technology-Enhanced Education: Ubiquitous Learning and the Digital Native. IGI Global, Hershey, 2009 2. Boyd, d., Golder, S., Lotan, G.: Tweet, tweet, retweet: Conversational aspects of retweeting on twitter. In Proceedings of the HICSS-43 Conference, January 2010. 3. Costa, C., Beham, G., Reinhardt, W., Sillaots, M.: Microblogging in Technology Enhanced Learning: A Use-Case Inspection of PPE Summer School 2008. In: Proceedings of the 2nd SIRTEL workshop on Social Information Retrieval for Technology Enhanced Learning, 2008 4. Ebner, M.: Introducing Live Microblogging: How Single Presentations Can Be Enhanced by the Mass. Journal of Research in Innovative Teaching (JRIT), 2 (1), p. 91- 100, 2009 6. Ebner, M., Mühlburger, H., Schaffert, S., Schiefner, M., Reinhardt, W.: Get Granular on Twitter - Tweets from a Conference and their limited Usefulness for Non-Participants, accepted paper at Workshop (MicroECoP). WCC 2010 conference, Brisbane, Australia, 2010 7. Ebner, M., Reinhardt, W.: Social networking in scientific conferences – Twitter as tool for strengthens a scientific community. In: Proceedings of the 1st International Workshop on Science 2.0 for TEL, Ectel 2009, September 2009 9. Grosseck, G., Holotescu, C.: Can we use twitter for educational activities?. In Proceedings of the 4th International Scientific Conference eLSE ”eLearning and Software for Education”, April 2008 12. McGiboney, M.: Keep on tweet’n. March 2009, online.com/blog/2009/03/20/keep-on-tweetn/ (last access: 2010-04) http://www.nielsen13. Reinhardt, W., Ebner, M., Beham, G., Costa, C.: How people are using Twitter during Conferences. In: Hornung-Praehauser, V., Luckmann, M. (Eds.): Creativity and Innovation Competencies on the Web. Proceedings of the 5th EduMedia 2009, Salzburg, pages 145156, 2009. 14. Templeton, M.: Microblogging defined, http://microblink.com/2008/11/11/microbloggingdefined/, 2008, (last access: 2010-04)
Connecting Early Career Researchers: Investigating the Needs of Ph.D. Candidates in TEL Working with
Web 2.0 Nina Heinze1, Marie Joubert1, Denis Gillet1
1 STELLAR Network of Excellence n.heinze@iwm-kmrc.de, marie.joubert@bristol.ac.uk, denis.gillet@epfl.ch
Abstract. This article describes the results of a case study conducted amongst 21 doctoral candidates and three senior researchers at the Joint European Summer School on Technology Enhanced Learning 2010. The study aims to analyse the needs of early career researchers working within the field of TEL in geographically distant communities, particularly with respect to online collaboration, communication and information exchange. This study can be seen as a needs analysis on support structures to enable research 2.0 in TEL among young researchers.
Keywords: communities of practice, Research 2.0, Social Media, Web 2.0,
case study, awareness support
1 Introduction
Our personal experience suggests that collaboration and communication within the
European TEL community usually looks like this: researchers use many offline and
web-based tools to work and to share their findings and opinions, there is no
standardised way of communicating, and various channels are used to disseminate
information. It is difficult to keep up with who is doing what in the field, though
many researchers are making a considerable effort to monitor the data that is being
spread on the Web by colleagues [
Some efforts have been undertaken to make it easier for doctoral candidates to stay
up-to-date on current topics and events and to enable them to collaborate online.
These include the establishment of inter- and transorganisational mailing lists,
newsgroups, social media groups or forums1. Despite these efforts, however,
anecdotal evidence from our discussions with Ph.D. students indicates that doctoral
candidates still feel that support in terms of information and collaboration could be
improved. To address these concerns, the STELLAR Network of Excellence2 supports
doctoral events that aim to improve collaboration and communication between junior
and senior researchers as well as enhance the flow of information. In addition,
STELLAR also plans to create a virtual doctoral community of practice (DoCoP) to
help Ph.D. candidates stay in touch, share and conduct research, help each other solve
problems and get in touch with further junior and senior researchers by means of Web
2.0 technologies, the latter being nowadays referred as social media. We understand
Communities of Practice (CoP) to be a group of people who share the same interests
and passion for something they do and shape their identity by a shared domain of
interest whilst engaging in activities around this domain with other members of the
community. They thereby develop a shared repertoire of resources, a shared practice,
as Wenger calls it in his explanation of a CoP [
We saw it necessary to develop an understanding of the needs of Ph.D. candidates as the starting point for the development of the DoCoP planned in STELLAR. Our first step towards developing such an understanding was to consult with Ph.D. candidates.
An opportunity to do so arose at the 2010 Joint European Summer School on Technology Enhanced Learning, which took place in June 2010, gathering together about 50 Ph.D. candidates working in TEL. We conducted a workshop with focus on students’ views on the creation of a doctoral community of practice in the field of TEL. 21 doctoral candidates as well as three senior researchers participated in the workshop. We asked them about what type of information may be of value to them to increase awareness in terms of collaboration, what type of awareness support would be of use to them, what tools they use when collaborating in dislocated research teams and how they believe a sustainable community of practice can be implemented. We report about our findings below. 2 Consulting on a DoCoP with Ph.D. Candidates in TEL – A Case Study During the workshop at the Summer School the doctoral candidates worked in groups of 5-6 people and were asked to discuss how they would wish to receive support for their doctoral work in terms of personal support, awareness support, tools for collaboration and the characteristics of a doctoral community of practice that would be of value to them. Each group then presented their findings, explained their results and engaged in discussions about their thoughts with the other participants of the 1 Examples include JTEL Summer and Winter Schools, Doctoral Consortia at conferences like EC-TEL or Earli, the STELLAR Mobility Programme or DocNet from the University of St.
Gallen, Switzerland 2 http://www.stellarnet.eu workshop. We recorded the entire session to be able to further analyse the results after the Summer School. 2.1
Results of analysis of needs of Ph.D. candidates in TEL
We analysed their reported needs and categorized them into two levels, each describing the personal involvement or gain of the individual researcher (see Table 1). The individual level of needs describes issues that occur on an individual level like review of one’s own paper or managing one’s own information. Support on this level aids the individual in her endeavour more than it does a larger peer-group. The community level is the actual community or peer-group level. Support on this level is useful for more than the individual researcher. A larger CoP would benefit from assistance on this level. Table 1, below, summarises the findings within each of these two categories.
As we can see from Table 1 doctoral candidates would, on the one hand, appreciate support on a very individual level concerning the process of finishing their Ph.D. thesis like advice on the methodology they are planning to use, how to solve problems they encounter when doing their research as well as meeting face to face with a senior scientist to discuss their work to be able to better evaluate if they are on the right track. On the other hand, doctoral candidates see the need for a community of peers working in related fields to network, discuss their work, get a notion of where others in the field are, what their work is about and how they cope with writing a Ph.D.. In addition they would like to get feedback from a community of peers on their work and share research findings and data.
When we asked them about how they believe they can be supported in their endeavours and needs on a technical level we received answers related to information gathering like RSS feeds from relevant sites, collaboration tools like a semantic wiki with an ontology as well as information filtering tools like recommender systems and a reputation system to enable them to better match the information with their current needs. The proposed solutions Ph.D. candidates gave revolve around support issues that have a high technical (system) component. They require the provision of some sort of Web 2.0 tool or are in essence already a tool.
What we can see from the distinction we made is that the categorization of needs in two levels is not a sufficient distinction, since some issues on the individual and community levels are at the same time themes that fall into the area of proposed solutions like networking or sharing testbeds. This is not a surprise, though, since communication, collaboration and awareness of a community go hand in hand. 2.2
Results of awareness support of Ph.D. candidates in TEL In addition, we asked the 4 groups to consider what kind of awareness support may be helpful in research communities with respect to contributing to increased productivity. With awareness we mean the state or quality of being aware of the current themes, projects, events and researchers including their background within the field of TEL and one’s own position within it. Again they discussed within their groups and presented their findings in a plenary.
We analysed the plenary discussions and were able to place the findings into two areas. The first area, personal, pertains to information available on the personal/professional background of other researchers and contains topics like research background or projects that the person has worked on. The second area of interest in awareness support, research, concerns information on the actual output of researchers (artefacts like publications) as well as opinions of others about them. Table 2 sums up the awareness support results of the case-study participants. Table 2 shows that doctoral candidates wish to have personal information on people within their area of research in terms of scientific background and expertise, as well as their online handles like Twitter and delicious user names or blogs. On the research level they suggest information on current artefacts and publications, as well as the state-of-the art of research in their field and opinions from peers on research, publications and other researchers.
When asked about technical solutions to make it possible to gather and filter information within the community to increase one’s awareness of the field of TEL in terms of people, topics, and events, the Ph.D. students proposed open-source solutions to share datasets as well as reputation mechanisms to increase awareness of and within the TEL community. However, the results on the tool level were low which we believe is due to the fact that there are few good services available and the time we gave the doctoral candidates was too short to come up with productive and creative feedback. 3 social media handels are usernames for social media services like Twitter, Delicious, Slideshare or URL’s to blogs or wikis 2.3
Suggestions for the creation of a doctoral community of practice by Ph.D. candidates in TEL
The last part of the workshop revolved around collecting ideas on how a sustainable virtual doctoral community of practice (DoCoP) amongst former and future Ph.D. candidates participating in STELLAR doctoral events could be established and maintained. We saw a key consideration within this discussion as the tools used to support the DoCoP. Further, participants were also asked which Web 2.0 tools they use in their own practice and for what purposes in order to inform our understanding of what they value. This discussion, again, took place amongst the whole group.
Our analysis of the discussions led to three main results. The first is that the participants in our case study find it unlikely that a larger doctoral community of practice can be sustained in a reasonable manner by itself. Their experience is that events such as, for example, the Summer School, function as an umbrella, or a macrolevel of community, out of which several smaller, actual communities of practice arise with about 6 to 10 members. The Ph.D. candidates suggested that these smaller communities of practice should be supported not by a particular tool or service, since the community members would decide on those depending on their needs and habits, but rather by the provision of guidelines on collaboration, including the use of existing Web 2.0 tools for research and community management.
The second conclusion the participants drew was that the sustainability of a community of practice, based on the philosophy underpinning Research 2.0, would be highly dependent on individuals dedicated to it. They concluded that the community is independent of the tools in the sense that tools are used regardless of the community. Participants recommended a community facilitator to keep the flow of information going and the community members active in participating.
The third conclusion was that the tool or service needs to fulfil collaboration and communication functions and should be user-friendly in the sense that it is easy to use. The doctoral candidates already use a number of tools for these purposes as well as for research and the organisation of their projects, they did not see the pressing need for a “new” tool or platform.
Table 3, below, summarises the participants’ reported use of Web 2.0 tools for communication, collaboration, research instruments and organisation.
Communication x
Collaboration x x
Research
Organization x
Tool E-mail Google Docs Google Talk Google Scholar Google Analytics Google Forms Google Sites Google Wave BSCW Dropbox x x x x x x x x x x x
Mendeley Group Wikis FlashMeeting Skype MSN Messenger Doodle Gigapedia
Library 3 Conclusions x x x x x x x x x x x x Acknowledgement