From Bodington Wiki
Back to TReCX
This section of the wiki contains all the documentation pertaining to the JISC-funded TReCX project (see http://www.jisc.ac.uk/project_trecx.html). This is a historical document, current documentation is to be found elsewhere on this site. The project ran from 1st Feb 2006 until 31 Jul 2006.
The project will begin by documenting a series of use cases from a variety of e-learning contexts which will generate the requirements of the services. At the same time we will survey the current state of tracking services and standards to see what is available; we will specifically look for mature open source software and open standards in the appropriate areas.
The next phase will detail the architecture of the toolkit based on the requirements from above. The software will be produced following the quality guidelines set out by JISC and will strive to produce a simple lightweight service that can be easily used by third parties whilst leaving extension points for future development.
We will provide a toolkit which addresses the Tracking and Reporting ELF services and provides the following components:
- a tracking application (centralised repository) [Java]
- a reporting application (web-based client) [Java]
- a tracking service interface (to write events to) [WSDL]
- a search service interface (enabling querying of applications that maintain repositories of tracking data) [WSDL]
- guides on how to augment existing e-Learning applications with tracking (search and publish) behaviour.
Oxford University have deployed Bodington as their institutional VLE. In order to extend functionality it is essential that all external services are able to report events to Bodington which it can then use in its notification system, (where a user is able to select an option to send a daily email regarding events that happen on selected resources). Over the next year we intend to add a number of open source systems: a forum (possibly MVNForum), a Java Wiki, a reading list (MDC) and a PDP system (LUSID); all these services will require some degree of tracking.
We will demonstrate use of the above toolkit elements using at least two existing applications: the Bodington VLE which has its own internal tracking store and an instance of an application which does not maintain it's own tracking respository such as a forum, wiki, chat tool, etc. All additions will be contributed back to the community.
To allow cross application tracking to happen, a system needs to expose tracking data to an external tool in a standardised form. There are two scenarios to cater for.
Application performs no tracking: enabling all systems to contribute tracking information back to a remote store allows reporting on that information to be performed in an effective manner. It also helps to standardize the information given by the applications so that there is a consistent data format. This is more appropriate where the tool does not currently provide any useful tracking information and the privacy of the information relates to the user who is being tracked.
Application performs its own tracking: in this case one would implement a standard search client interface to each tool which can then be queried over a Web Service call. This allows existing repositories of tracking data to be incorporated into a report. It is also more appropriate where different data should be returned depending on the resource being tracked.
As long as a service or application implements the search interface then a reporting application can build a complete profile from all tracking stores. Put another way, there is also no reason why tracking information couldn't be stored in more than one remote store, indeed we imagine that this will often be the case. The reporting service will produce data in the following formats: xHTML / CSV / iCal / SMTP.
In addition the toolkit will include WSDL and Java interfaces to support the implementation of tracking service clients and search service implementations within existing applications. The nature of the service interfaces will be implemented using either REST or SOAP depending on what our initial requirements gathering reveal.
What do existing applications do in the form of tracking?
A distillation of generic use cases to be pursued by this project.
Functions that the system should support from the user perspective.
Design issues. How we intend to implement the system as opposed to what it's supposed to do.
The kinds of e-Learning applications that serve as good examples.
Candidate technologies such as various web service standards, AOP, general tools, etc.
Logical and implementation views of the system (including UML diagrams).
Security issues identified by the project.
Issues concerning individual data protection and privacy.
Quality plan (including the testing methodology).
How we intend to promulgate our work amongst the wider community.
People who need to be informed of progress.
Documentation of standards used in toolkit.
Documentation of the source of all 3rd party code and licence info.
Problems encountered and solutions offered.
Work packages and milestones of project development. Exit strategy.
Key dates of project meetings.
- Notes - initial technical discussion gathered from a variety of sources.
- Blog of Alexis (developer) (or here as an Atom feed ).
- Blog maintained by Adam (Project Manager) (or here as an Atom feed ).
- sourceforge TRECX web site which hosts the project software artefacts in downloadable form.
- Browse SVN source code of project software artefacts under version control.
Back to TReCX