Friday, September 08, 2006

TReCX website & blog on the move

We have had to move the TReCX website. The gateway for the site is on the JISC E(L)F site (which, I note, is appalingly slow at the moment). On this site you will find links to the TReCX site which currently resides on the Bodington.org Open Source VLE site wiki.

Keen observers will also note that this blog has moved. The TReCX management blog was hosted within my personal blog which was a non-too-ideal situation, now it is here! I have replaced all references to the TReCX wiki so that they all contain the current URL.


Trecx and Moodle

Consider this scenario: an institution is running several Moodles. As part of a course, a student will need to 'do e-learning stuff' in each of these Moodles. Maybe there is one Moodle per course or something! A tutor would like to see a coherent report on the student's activity without having to enter each Moodle separately, generate a series of separate reports, and then manually collate all the tracking data.

Trecx should be able to help here, however, the caveat is that the toolkit is written in Java and of course moodle is PHP. That is not to say that Trecx cannot be useful, it's just that the ‘helper’ software will not be of any use. The tracking store and reporting application will still be useful though.

What the Moodle administrator will have to do is implement the ‘search interface’ so that it retrieves data from the moodles. A configuration file should be created which tells the Trecx reporting application the URLs of all the moodles and the reporting app will then query each moodle and collate the separate tracking data into a coherent whole.

More information can be found in the Trecx
wiki
, specifically look at the DesignIssues and FunctionalRequirements pages.

You may find my and Alexis’ blogs useful (link at bottom of wiki front page).

As happens with these things, we are atrociously behind where wed hoped – this is mainly due to me missing 4 weeks of work near the start of the project (leg operation) and then taking my eye off the ball for 3 more weeks whilst trying to catch up with my other tasks! And then everything takes longer than hoped!

So what we will end up with is a toolkit but no demonstrators: we had hoped to demonstrate the software working with Bodington VLE and a forum (MVNForum). We should have been able to track a user as they followed links in the VLE and then ended up in the forum where they posted some messages. The reporting application will show where this user has been.

What we’re actually going to end up with (fingers crossed) is a demo which uses an application to simulate a student ‘doing e-learning stuff’ – this application will send its tracking data to a tracking store. We will do this 2 or 3 times and use 2 or 3 tracking stores. This will give us 2 or 3 ‘systems’ containing tracking data (each equivalent to your one of moodles) – the reporting app will then query these 2 or 3 tracking stores and collate the data and present it back as a chronologically ordered ‘audit trail. That’s the theory any way!

What would be a useful exercise for a Moodle expert is to look at what events we are thinking that an e-learning app will generate (see wiki) and see if Moodle does indeed store any of this info. If it does not then think if one can add code to moodle to get it to send ‘events’ to the Trecx tracking store. One should also consider the search interface we propose and think whether implementing it for moodle is a possibility.



Trecx schemas now on the web

We have defined schema for configuration of all the various bits of software.

The schemas are accessible via http://bodington.org/wiki/index.php/Trecx:DesignIssues

These schema were ceated using the following process (which worked very well):

  1. Create an instance of a valid document using a text editor
  2. Using Oxygen v7, select the 'learn' facility and save the resulting DTD
  3. Use the Trang tool in Oxygen to convert to an XML schema
  4. tidy up the schema's and lock down

TReCX Managament Issues

Due to problems with staff sickness (project manager), paternity leave (developer) anmd underestimation of timecales, the TReCX project has fallen a little behind.

We have has a look at the project plan and have decoded to remove two workpackages from the project. These workpackages are not central to the completion of the toolkit, in fact they we two 'demonstrator' type chunks of work. We had planned to test out the tracking and reporting toolkit by
  1. using aspect oriented programming to get MVN Forum to use the tracking store
  2. using the Bodington VLE to implement the search interface.

Both these workpackages have now been dropped.

The toolkit should still be completed on time and we should still be able to give a demonstration, however, this demo will be different to that envisaged at the start of the project. We will be able to use 2 (or more) instances of the tracking store to demonstrate that the reporting application works.

Trecx - why not store all data in the remote tracking store?

We are often asked: 'why not just get every tool in a WAFFLE to post its events to the remote tracking store'?

Our response is

  • why store the same data twice? If the data is stored internally in an application then let us leave it there!
  • tools that store their own tracking data may well have the notion of users having to be authorised to see the tracking data. It is not feaible to post this information to a remote store (as access permissions may be changed after the event). So we need to leave already collected data 'in place'.
  • a target application may require less modification to be searched than it would to send its events to a 3rd party.
  • in some cases (with closed source tools) it may only be possible to access the database and not the source code, ie, the database can be searched with no modifications the to the application that drives it. A facade could be written to do this.

http://bodington.org/wiki/index.php/Trecx:DesignIssues

We're also wondering about the query interface. We were going to use XQuery but then realised that interfacing XQuery with an arbitrary SQL database will be a large task way out of scope of trecx, so we're having a rethink.

We believe that the tracking store is not a complex piece of software; one of the cornerstones of Trecx is to keep things simple, ie, simple message structure, simple security, simple message format and simple RESTian WS interface.

We are intending to use Aspect Oriented programming to demo how 3rd party tools can be 'instrumented' to produce otherwise unavailable tracking data.

Brief summary of Trecx that even your granny would understand.

The idea behind trecx is two fold:

  • we create a reporting service which uses a standardised web-based query interface to interrogate distributed event stores and present back collated tracking data
  • we provide a stand alone tracking event store that can be used by tools that do not currently hold tracking data. We will use Aspect Oriented Programming to extract events from this sort of tool and send them to the store.
So, in our scenario, the reporting service will interrogate Bodington (our institutional VLE which has its own event store) and the Trecx tracking store, which is holding event data from MVNForum (and say, Jabber, or any old tool that doesn't do this itself).

The AOP will produce an Atom / RSS / SMTP message containing an event list which is posted using HTTP to the tracking store for processing.

Trecx project progress

The TReCX project website which was private until today, has now been opened up for public view access. Members of the public will NOT be allowed to edit pages in this wiki (due to internal policy decisions).

Please contact me if you want to contribute to the web site in any way.

Note that the 'file upload' facility of the wiki is temporarily disbaled so all the images are missing. this will be rectified in due course.