Skip to content.
Sections
Personal tools
You are here: Home » Features » Group Calendar Web Service toolkit project

Group Calendar Web Service toolkit project

Christina Smart
Last modified 03 Dec, 2007
Published 03 Dec, 2007
Selwyn Lloyd describes the recent Group Calendar Web Service toolkit project which is designed to enable interoperability between institutional calendaring systems.

The fourth cohort of toolkit projects has just finished. Over the last few years the programme of projects has taken the pragmatic approach of enhancing the capacity for web service development within the UK HE and FE sector [1]. Projects have focused on key problem areas for institutions such as transferring assignment mark data or student information between institutional Management Information Systems.

Interoperability between calendaring systems is a universal issue that has not received much attention in the programme so far (With the exception of the Sweet.net project [2]). We spoke to Selwyn Lloyd of Phosphorix a small open source development company about the Group Calendaring Web Service project and what the toolkit will enable institutions to do.

CS: Could you tell us something about your company Phosphorix and the developments you’ve been involved with over the last few years?

SL: Phosphorix is a slightly unusual company, though I think one of many now emerging with a community ethos, particularly for open source in education [3].

We have spent the last five years developing open standard and open source software solutions and free software systems for education, mainly ioNode, ioNetworkNode, ioMorph, and ioPortal (io stands for interoperability not a funky apple widget) [4]. Our main focus has been on developing systems to link up institutional MISs for learner records and course information into interoperability frameworks and networks.

Our other areas are e-portfolio, PDP, CPD, learning design and social networking portals.

We first became involved with the JISC, through the SHELL MLE project in 2001 [5]. Since then outputs have been taken forward by the Learning Matrix project (John Moores Liverpool and partners) [6], the PDP4Life project (Bournemouth and partners) [7], the EELLS project (Hertfordshire and partners) [8]. We now work concurrently on a number of projects as partners and collaborators.

SL: Firstly we were looking for ideas for small web services, particularly a service which could be shared across applications or even organisations. The e-Learning Framework and e-Framework [9] had mapped out a number of potential common service requirements and we knew the terrain well enough from intranet type developments. Having met with the Tetra community [10] prior to the call for projects, we tabled a number of ideas including a "calendaring" web service for groups or networks of users.

Developing a calendaring web service isn’t as simple as you might think. When you think of all the systems that use a calendar or require scheduling, it impacts on lot of systems and end users. Within the education world that might mean all kinds of learning environments, learning events and curriculum timetables. With RSS and other feeds we had seen rapid adoption of methods to link history. Perhaps in a novel way, when ioPortal developers embraced RSS and blogs we identified an opportunity to take the blog metaphor further. In fact back to its roots which we believed to be in diaries or journals not just "logs". By the time we began the GCWS project we had a plethora of use cases for planning, organising, scheduling and recording stuff which might be easily viewed in the context of calendar views [11].

CS: The Tetra Collaboration was set up in 2006, what has been the involvement of the Tetra community?

SL: Right now the Tetra community are the closest thing Phosphorix have to an OSS foundation or an ideas incubator, we are very proud to be included in that, it’s a sound community. I remember Tetra concepts being discussed at one of the ELF developer forums [12] when the toolkit programme first started. It seemed to me that an aim of Tetra was very similar to that of ionode, to develop common modular services that join systems together across a distributed network or a service oriented architecture.

In the same way that the ELF attracted our interest for intranets or the enterprise, we found that a certain Tetra concept seemed to embody the concept of the interoperable widget and this was most attractive. We understood the widget to mean something which would fit into one or more systems. Members of the Tetra community, particularly colleagues from UHI, Oxford and Cambridge, shared use cases and requirements for a GCWS. They also shared insights into standards they would like to see investigated. They helped us with the type of licensing needed so project outputs could be used in their respective projects. Colleagues in the Tetra community were always helpful with sourcing OSS solutions helping us avoid reinvention where possible and finally be prepared to bounce ideas back and forth.

CS: How will GCWS help teachers and learners within institutions collaborate?

SL: GCWS will allow teachers and learners to share a learner’s calendar, indeed calendars could be based around an individual learners plan and shared with their tutor, mentor or teacher. However there are many ways groups of learners and or teachers might network together and many activities within organisations are date and event dependent.

CS: You’ve been gathering use cases from the project stakeholders, can you give some examples of these?

SL: We began by doing quite a lot of research into existing open source calendaring tools. We wanted to do something different from them. It is already possible for one or more people to share calendars on the web using systems like Google calendars [13]. One thing those systems can’t do is allow people to write to the same calendar using a wide array of clients, while maintaining a unique copy individually, GCWS allows users to do this.

It’s important to say that we didn’t set out to create a new calendaring application. GCWS was about enabling interoperability between existing legacy systems. GCWS can transform legacy calendar data into .ics or rss format through a transform service.

The GCWS allows one or more institutions to share calendar information and aggregate calendars. These aggregations can then be shared with the outside world. You can imagine a number of applications for this, for example there might be a gig on at Exeter University, GCWS could be used to export details of the event as a calendar file to make the information publicly available. This model is very similar to what XCRI are doing with course data [14].

In terms of scheduling we have taken a pragmatic approach. Some systems search for meeting times across several calendars. However that relies on users keeping their calendars up to date, some people are very organised, others less so. We have taken a more pragmatic approach based on the "Meet-o-matic" model [15] which allows users to say when they are free. Within HE and FE this would enable a tutee to schedule a meeting with their tutor, but it has much wider application too.

One of the constraints of running a project in such a short timescale is that we had to prioritise developments, and that meant leaving some use cases until after the funding had finished. One of the use cases that came from the team at Oxford University was the ability to import and export calendar files into and out of Bodington [16], we’re looking at that now.

CS: Can you briefly describe how GCWS would interact with existing institutional systems?

SL: GCWS RC (release candidate) 0.1 was very much a toolkit to build your own group calendar web service by integrating with existing systems such as the VLE. Technically, a project can start by installing an ioMorph plug-in which can be configured to read in data and provide output calendar feeds. The feeds of existing calendars can thus be viewed or shared with a group or individual when included in that group’s calendar. In GCWS we wrote a transform ioMorph service for iCalendar files (.ics) and RSS. This enables data from different legacy systems to be re-used by GCWS and other compliant software. Also in RC 0.1 we used a DAV (Web-based Distributed Authoring and Versioning) service to allow people to post .ics files directly to a group calendar directory.

Ics publishing is a feature of many calendaring systems and some institutional systems may already support ics or rss outputs. GCWS can handle either and will uniquely aggregate the calendar feeds of many people into a joint calendar. We developed a directory watching service which copies the latest version of a calendar and merges it with the previous version. The GCWS hub maintains the unique contributions of the group members in separate folders after it receives them via the DAV interface, we used Apache Slide for the initial Dav service.

Regarding the core aggregated calendar web service API, the VLE would pass an identifier for a logged in user such as a unique enterprise username or an email address to the core GCWS web service url. In the project we created a group creation service in ioPortal and tested registering individuals. Batch handling of usernames or emails has yet to be tested in anger. Once a user is registered they have their own unique group and can create new ones themselves or join existing groups. Users may invite others to join their groups and thus share a calendar.

CS: What were the main achievements of the project?

SL: I think one achievement was working with the stakeholders to attain use cases which would meet their scheduling and calendaring needs. Also interoperability with email client based calendaring and enterprise utilities. I think we’ve established unique features which were also beneficial. We’ve also found other projects which wanted to take the outputs further or indeed integrate them.

CS: What have been the main challenges?

SL: Keeping the development on track with other projects under development at the same time is a big challenge. The timescales were very challenging and it has meant that we have had to plan do a number of interesting things beyond the grant funded phase.

CS: How will you be building on this work in the future?

SL: I remember being told in the start-up meeting for this set of toolkit projects that we should "plan for success" and think about what the impact would be on us if the project was successful. As we’re a small business it’s very important that we do plan for success, and we’ve got a number of new projects in development as a result of GCWS.

The other projects require different calendaring and scheduling features, these help us to develop the GCWS further. We are also looking at shared calendaring services between many institutions in a given region and are partnering with Lifelong Learning networks to make sure that future work remains useful to many stakeholders.

We are already developing GCWS 0.2 beyond the funded phase and hope to be demonstrating and launching this at the JISC-CETIS conference this year [16].

CS: You've been developing web service technologies for education for a number of years now, how do you feel these technologies are being taken up by FE and HE institutions?

SL: One problem that hasn’t gone away is that it’s hard for people to buy into something that is constantly changing, it undermines confidence.

For the further and higher education sectors both the standard of education and technology interoperability standards are constantly changing. It seems to me that with respect to interoperability this has sometimes caused a lack of confidence and sometimes scepticism, maybe excuses. Conversely within processes of educating change we see change is a good thing, it’s agile and evolutionary.

What we need to do is see this constant change as an opportunity not a problem. Over the past few years I’ve seen resistance to web services by Information Services managers, but projects like XCRI have started to change minds because they provide an opportunity to improve systems gradually [14]. I think being able to export course data in XML format wasn’t the most important part of the XCRI project. It was that those people involved in the project had to think about the processes they used in their institutions for creating and sharing course data. And by understanding these processes they were able to re-engineer them to work better. So developing standards and specifications like XCRI provides a catalyst for improving existing systems. The work we’re doing with Calendaring is very similar to the XCRI model in that it will allow institutions to publish, share, and aggregate calendar information and with any luck also be a positive catalyst. We feel there is a very real and exciting demand for calendaring now.

CS: Thank you Selwyn

References

[1] Evaluating the Toolkit and Demonstrator projects

[2] Sweet.Net project

[3] Phosphorix web site

[4] ioNetworkNode

[5] SHELL project

[6] Learning Matrix project

[7] PDP4Life project

[8] EELLs project

[9] e-Framework for Education and Research

[10] Tetra collaboration

[11] GCWS project web site

[12] ELearning Framework Developer Forum

[13] Google Calendars

[14] Exchanging Course Related Information

[15] Meet-o-Matic

[16] Bodington

[17] JISC CETIS conference 2007

 

Supported by JISC Supported by CETIS
Powered by Plone