WS4RL - More information
This project has built on the recent successes of CETIS LIPSIG, the Centre for Recording Achievement (CRA) and the work that has been completed as part of the Developing Learner Profiles across FE and HE initiative funded under the Managed Learning Environments (MLEs) for Lifelong Learning JISC project. Members of the project team have also been involved with the TransportALL project and have been instrumental in the mapping of the PDP domain to the IMS Learner Information Package (LIP) specification.
The JISC e-learning framework (ELF) defines a structure for the implementation of a Service Oriented Architecture and has a box for ‘Personal Development’. Prior to the start of this project, there was no consensus about what a PDP Web Service would look like. In order to fill in the appropriate box, it is necessary to examine the PDP domain to see what kind of service makes sense.
The WS4RL project draws together experts both from the field of PDP and from the ELF development community who have worked together and looked at how PDP is used in practice and, from this, have worked out exactly what such a service should look like. We unexpectedly discovered that two different web services would actually be needed: one is the anticipated PDP web service (which is actually quite coarse grained) and the second is a Personal Information Management Service which handles the storage and retrieval of data.
Aims and Objectives
The initial aims of the project were to develop a process model of both the planning and reflection aspects of PDP. These models would inform us of what a PDP service would look like. We intended to use this information to produce an SDK for implementation of a PDP web service (this, we thought, would be similar to the Enterprise Services toolkit already produced by CETIS). The SDK would then be used as a basis for implementing a demo service using the LUSID PDP system as a target.
We are fairly happy that we reached our main objectives, however, the definition of the PDP service turned out to be a lot more complex that we had initially envisaged. Moreover, when we cross-referenced our work with the findings of the EPPI group, it soon became apparent that a Personal Information Management Service was absolutely central to this project. What is needed was a data collation service that could be used by both PDP and e-portfolio systems. This is influenced by the fact that a learner’s personal information is likely to be stored in a series of distributed databases – the situation will be unmanageable if different electronic systems have to maintain a list of all of the databases which contain learner information records. What if one system created a very important record which the other systems were not aware of? Much more time was spent looking into solutions to this problem than we had intended.
The objective of producing the SDK(s) was achieved satisfactorily – the code has been released through the WS4RL Source Forge site. The distribution includes all the java classes needed to implement an AXIS-based service plus the service definitions (WSDLs) complete with all the necessary schemas and build files for rebuilding the java classes.
We are well aware that PDP cannot be easily specified or modelled normatively (any more than can education or learning in general). Rather than try to offer an overall model of PDP, we set out a model of one possible process which we call “personal theory building”. This process at least conforms to (i.e. fits within) the definition of the nature of PDP arrived at by the EPPI group which undertook a systematic review of research relating to the effectiveness of PDP. (This group agreed that PDP must include reflection together with at least one other process out of recording, planning and action.)
We are then able to detail and formalise the process of personal theory building, partly so that it can in principle be represented using interoperability specifications such as Learning Design (LD), and also in order to show how this can be related to previous categorisation of PDP activities done in the PDP survey. Sample scenarios are presented and explained in UML.
The main purpose of formalising such a process is to prepare the ground for it to be offered as a web service. The second half of the project takes this forward, by setting out a future architecture for web services in PDP, detailing some of the most important web service calls, and discussing and illustrating how web services would be used to implement the two main scenarios of use of PDP: firstly where PDP is embedded in other learning, and secondly where it is free-standing. Some examples from the first half are brought in, to illustrate how this could be done for typical PDP processes.
PDP often involves reviewing previously stored records and creating new ones – including information about educational and other activities, achievements or qualifications, skills or competencies, goals or aspirations, interests, and the products of and evidence for many of those things. These same records also relate to e-portfolio usage, and selections could be presented to other people for a variety of purposes. Recognising this, central to the presented architecture is the factoring out of records-related functionality from PDP process-related functionality. We identify a major architectural component that we have termed the Personal Information Aggregation and Distribution Service (PIADS), which is used by the PDP web service. This may also be used in other contexts such as a Shibboleth Attribute Authority.
The purpose of the PIADS is to give learners, as owners of information related to themselves, the facilities to manage the storage of and access to that e-portfolio-related information. Learners will be able to choose from possibilities of where particular information is to be stored, and who is allowed to access it. As PDP is closely tied to much of this information, it makes sense for any PDP web service to use through the same PIADS service.
Again, because of the same close relationship of PDP and personal information, one cannot specify in detail what PDP services can be offered independently of the information about the learner. Even in an e-learning context, the PDP interaction has to be a dialogue, with the learner asking to do some PDP, and the PDP services asking more about the learner to determine what is appropriate.
Much more information can be found by looking at the project files (in the column to the left) - the discussion document gives a particularily good introduction. The more intrigued reader should look at the full rationale document
Last modified 2005-05-25 06:17 PM