Navigation
SEARCH
TOOLBOX
LANGUAGES
Create a book
STELLAR Network of Excellence
PreDeliverable
Create a book

PreDeliverable

From Stellar Deliverable 6.3

Jump to: navigation, search

Contents

1 D6.3 First iteration of STELLAR mash-up

The STELLAR WebSite will be initiated. It will contain a first set of mash-ups of general available web 2.0 and social software tools applied to TEL data sources. These mash-ups will be the basis for further refinement. 

 The official  DOW part on the deliverable is:
 D6.3 First iteration of STELLAR mash-up. The STELLAR  WebSite will be initiated. 
 It will contain a first set of mash-ups of general  available web 2.0 and social software tools applied 
 to TEL data  sources. These mash-ups  will be the basis for further refinement. 

 The official  DOW task description is: The task T6.1: TEL Science 2.0 Mash-up initiation  and 
  evolution: Within this task we will set up the mash-up  infrastructure and make it available first 
 within  STELLAR and in a second step to the wider TEL community. We will develop  a variety 
 of mash-ups of mainstream tools and more  specialized research oriented tools from the partners. 
 These mash-ups will be  available on the STELLAR web site (e.g. in the form of widgets to be 
 easily  embedded into web-applications).  
 The  work to be undertaken will involve the following steps for each of the  yearly cycles:
  requirements gathering, design of mash-up,  implementation of mash-up, evaluation of mash-up.

 Comment:  Switch methodology to design based research? user centred-design? At least  balance this 
 classical software development process  with some more agile!

1.1 vision

  This  section needs to elaborate on why we do this and where we want to go,  thus expressing requirements, goals, and objectives.

Science 2.0 can be researched only at the interface of a set of disciplines, most prominently including information science, information systems, computer science, psychology, sociology, and education sciences. In each of these disciplines relevant research areas can be identified by which light is shed on theory and practice.

Here are some definitions and claims.

WP6 has organised a workshop on science 2.0 at this year's ECTEL, see [here]. Especially the contributions from [Stefanie and Barbara] and [Denis, Sandy, Marie, and Ros] provide deeper insights into STELLAR contexts.

Additionally, the knowcenter team has contributed initial requirements expressed in the following use cases. Visions for future development are described in these scenarios.

The work on science 2.0 mash-ups relates to our overall STELLAR project objectives in the following way. First, it facilitates easy reporting and documentation of the activities pursued by the partners within and beyond the consortium. This is strongly related to the work on evaluation (WP7) and project management (WP8). Second, it serves the purpose of gaining more visibility for the work accomplished within the network. Third, it serves as an infrastructure for sharing, discussing, and interaction thereby paving the way for more interdisciplinarity. The mash-ups created have to be easy to use and easy to integrate with current working practices.

mention: cognitive offloading.

go through erik's bookmarks: http://delicious.com/erikduval/science2.0

add section explaining the development process / maturing process (sources&services, research prototypes, market-ready applications)

1.2 building blocks

1.2.1 Summary=

There has been a lot of work on various building blocks, all of them very different in nature. Some of the work has been contributed by [this] group and in the science proxies group's meetings (see e.g. [this recording] to catch up). Additional work has been contributed by the UKOU team. There is an ongoing effort by KC to build tools [and widgets around publication feeds based on rss and swrc.

We split up the building blocks in 2 sections. Building blocks can be data sources, services and applications.

The list of building blocks so far is:

1.2.2 data sources and services

1.2.3 data sources and services

There have been a couple of publications accompanying this work that document the work in more depth:

Ochoa, X., Mendez, G. & Duval, E. (2009): Who we are: Analysis of 10 years of the ED-Media Conference, In: Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications ED-Media 2009, pp. 189-200, see [here]

Fridolin Wild, Chris Valentine, Peter Scott (2009): Shifting Interests: Changes in the Lexical Semantics of ED-MEDIA, accepted for publication in: International Journal on E-Learning, see here

The description of the mini applications should include the following points.

  • Short description of the tool (what does it do)
  • Considered use case of the tool
  • Why it is especially appropriate for Science 2.0
  • Tool type: e.g. collaboration, awareness, communication, data aggregation, recommendation, visualisation, service finder
  • Development stage: (idea, prototype, release candidate, approximated date until the tool is stable)
  • Security concept if sensible data are involved
  • Description of data:
    • What data and what format (reference to standard) is used as input
    • What data and what format (reference to standard) is used as output
    • What data source is used (e.g. ectel, ed-media, dlbp, citeseer, …)
  • Description of APIs (e.g. REST call, if available)
  • Demo available at: URL
  • Openness: according to used exchange formats, source code, development process, …
  • Screenshot(s)

The structure of the description of the data sources or services could like as follows:

  • Short description of the data source or service (what does it do)
  • Considered use case of the data source or service
  • Why it is especially appropriate for Science 2.0
  • Development stage: (idea, prototype, release candidate, approximated date until the tool is stable)
  • Security concept if sensible data are involved
  • Description of data:
    • What data and what format (reference to standard) is used as input
    • What data and what format (reference to standard) is used as output
    • What data source is used (e.g. ectel, ed-media, dlbp, citeseer, …)
  • Description of API
    • A description how it works and technical specifications
    • A list of parameters available on the API
    • Description of the interface
  • URL of the service or data source if available online
  • Openness: according to used exchange formats, source code, development process, …
  • Evaluation: if applicable an evaluation strategy should be added. Measures can be selected from deliverable 6.2.

1.3 infrastructure

This section talks about the overall architectural framework and a little bit about the selection of a container platform as a starting point.

1.3.1 Characteristics of a TEL Science 2.0 infrastructure

- supporting communication

-- quicker feedback cycles

-- dissemination

- supporting collaboration (network building)

- fostering engagement (architecture of participation)

- research as perpetual beta process

- openness

- Focus on TEL data sources

- Focus on TEL functionality (tailored to TEL communication, collaboration, information visualization, recommendation needs)

1.3.2 Overall requirements of a science 2.0 infrastructure

- distributed

- open

- usable (end-user dev!) with the goal of a rich user experience

- ownership (institutes!)

- transparent usage monitoring (aggregate!)

- interfacing with legacy systems

- interoperable

- Widget directory/API directory

- Evaluation of TEL user needs

- joint user experience: common look and feel (elaborate a bit, mention possibilities such as CSS, but we will not solve this in the deliverable), put documentation on STELLAR corporate design into the annex

1.3.3 Mashups

Why mashups?

- lower user barriers

-- drag and drop

-- selection of tools

-- possibility to combine widgets

-- rich user experience

- lower development barriers for widgets

-- widget programming allows focus on functionality (e.g. data, visualization, recommendation provider)

-- mashup platform deals with authentication, user and group management, session management...

-- distributed widget development

-- mostly open APIs

- Ownership of and responsibility for widgets by widget developer

- programmable web


Abstract mash-up architecture diagram that shows how science 2.0 data and services can be wired into building blocks.

1.3.4 Interoperability dimensions

Here we have documented architectural dimensions for mash-up platforms in our field (together with folks from the Role project). The overall message is that none of the existing platforms satisfies everything, but that we should be able to plug together what we ever can think of thanks to open standards and a programmable web 2.0.

- Screen: Organization of several widgets within a PLE in a spatial manner

- Data: Interoperability of data and metadata across widgets and underlying services

- Temporal: live updates to widget configuration, state or data

- Social: Interoperability of user identity, profile information and list of friends

- Activity: controllable through scripts that engage the user into learning activities

- Runtime: exchange one rendering and execution platform or its parts with another.


Maybe explanation of standards such as xmpp in a glossary in the annex?


1.3.5 elgg

Elgg as an example widget container

- networking

- blogging

- file sharing

- news

Elgg and Wookie interoperability dimensions:

Space

- Shared screen: Wookie widgets integrated with an iFrame. Server side integration of plugins.

- Widget standards: Wookie widgets are W3C widget standard compliable.

- Layout of widgets: The Elgg dashboard has three columns for the ordering of the widgets.

- Web Desktop: Elgg does not mimic an Operation System.

Data Dimension

- Inter-widgets communication. Theoretical with wookie widgets possible.

- Drag and drop: Widgets are drag and drop able on the Elgg Dashboard.

- PLE data manager: Could be theoretical possible

- Linked data support: RSS Reader (like Simple Pie RSS Feed Integrator)

Temporal Dimension

- Push data updates: Yes. Instances of the same widget can share data.

- Push preference updates: Wookie allows to set preferences

- Real time data updates: No. Elgg and Wookie provide no special mechanism for real time data updates

- Data and preference history: No. Neither Elgg nor Wookie provide a special history mechanism.

Social Dimension

- List of Friends: Yes. In Elgg you can specify with what person, you are friend or colleague (with plugin)

- Friends server: Plugin for facebook connect (but just for login, not for friend list). No plugin found for open social

- Access control: Elgg has an access control mechanism (e.g. access to groups). Also with Wookie you can specify, if a single user or a group of user can share information (using the shared data key). Authentication with OpenID in Elgg is possible.

- Independent groups: No import mechanism for groups

Activity Dimension

- Manual guide: For Elgg and Wookie

- Flow enable widgets: With Wookie you can specify the lifecycle of a widget with widget.stop, widget.resume.

- Scripted inter-widgets data flow: No

- Recommendation: No

Runtime Dimension

- Feed export and import: Elgg can generate several feed formats with plugins (e.g. simplePie RSS Feed Integrator). Wookie can use data from other sources via the widget.proxify method.

- Generic export and import: No import possibilities for whole PLE configurations

- External configuration: PLE configuration could not be stored in a general form in a separate service

- Embedding: The entire Elgg can not be embedded into other PLEs, but Wookie widgets are embeddable in other PLEs like moodle.


Following this approach, the decision to use elgg as a starting point has been a strategic decision to align our work with the WP 5 community portal work.


Elgg will be used as the container for wookie widgets.

1.4 Annex

Retrieved from "http://www.stellarnet.eu/d/6/3/PreDeliverable"