Simon Grant, Adam Marshall, Janet Strivens and Roger Clark – Web Services for Reflective Learning
Reformatted for Simon Grant's publications
Simon Grant, Adam Marshall, Janet Strivens and Roger Clark
Version of 2004-11-01; references amended 2012-02-05
Keywords:
This is a summary of our attempt to define the nature of a personal development planning (PDP) web service. This work was undertaken as part of the JISC-funded WS4RL ELF project. The full project documentation (including the full version of this report) can be found on the JISC/DEST e-learning framework web site[1].
In this summary document, we will firstly develop some philosophical ideas on reflective learning as part of PDP, then, in the context of a couple of use-cases, propose some related web services (WS) that might serve in the cause of PDP. We will highlight a new common service – personal information management – which is responsible for a managing a single access point for a learner’s personal records, and will outline how a PDP web service must operate for it to be flexible enough to cope with the diverse system known to be out there.
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[2]. (This group agreed that PDP must include reflection together with at least one other process out of recording, planning and action.)
It is necessary to detail and formalise the process of personal theory building. This is partly so that it can, in principle, be represented using interoperability specifications such as IMS Learning Design (LD)[3], and also in order to show how this can be related to previous categorisation of PDP activities[4].
Increasingly, education in particular and learning in general is recognised as a process which can (perhaps should) be complemented by more general personal development, aimed at helping learners to be more autonomous and self-directed, and more able to choose, direct, manage and evaluate their learning throughout life. The role of what has come to be known in UK higher education, and some other circles, as “personal development planning” is thrown into sharper relief by the currently evolving context of learning. How are the vital PDP processes going to proceed in these new situations?
In response to this, firstly electronic tools and now web-based tools have been emerging from several sources which are intended to help support PDP processes. “Virtual Learning Environments” (VLEs) such as Bodington[5] now hold learning materials electronically, together with support for some of the processes which use or complement the materials, and these are intended to lead to more effective learning than plain self-study. The question then arises, can web-based PDP tools (such as the soon-to-be open sourced LUSID[6] system,) be integrated with e-learning, including developments from both Virtual Learning Environments (VLEs) and Personal Learning Environments (PLEs)?
Just as effective development of e-learning tools is helped by a clearer understanding of the learning process, so PDP tools need a clearer understanding of PDP processes.
PDP is defined as “a structured and supported process undertaken by an individual to reflect upon their own learning, performance and / or achievement and to plan for their personal, educational and career development.”[7].
Broadly, PDP activities can be categorised into those which look back on and analyse past experiences, and those which look forward, planning the next step or the ultimate goal. They are rather different sorts of activities and a learner may need to be supported to do each separately. They could be likened to the difference between hypothesis-building and hypothesis-testing. Some individuals find one easier and some the other, but both need to be undertaken if knowledge is to advance – in this case, the individual’s self-knowledge.
At the centre of these processes – between backward and forward looking, or between reflection and planning – stand learners’ theories of themselves. The aspect of PDP on which we are focusing relates closely to these central theories. While effective learners may carry out the processes intuitively, and build theories unconsciously, it often falls to the educator or PDP practitioner (or mentor, supervisor, life coach, friend, therapist) to make the processes explicit; or where they remain implicit, to offer appropriate guidance, direction and information so that the learner is more easily able to arrive at a theory which will be truly useful.
Our understanding of the nature of PDP is informed by direct experience of current practice; but also by a survey which started in 2003 as part of the work of the Centre for Recording Achievement (2004).
A major stimulus for creating a model covering reflective practice in PDP is to test out the idea that such processes can be represented formally. A formal representation is needed to work towards the offering of PDP as a web service, by any educational institution, employer or other body wishing to support PDP among people that are affiliated to it.
For this purpose, it is not necessary to try to detail all the practices and coverage of the whole area of PDP. In any case, there is likely always to be as much scope for diversity and innovation in PDP as in any other educational process. What is required is to illustrate a reflective process in sufficient detail both to enable readers to get a good sense that this is indeed the kind of process which is undertaken in PDP, and to test out in practice the a formalism to use for the representation of the process.
This PDP process model is then to serve as an exemplar and prototype for other PDP processes to be represented similarly, while not being in any way normative with respect to the contents. The level of detail of the model needs to be suitable for representation as a UML activity diagram. As the model needs to relate closely to PDP, and to be recognisable to PDP practitioners, so we have considered, with each major step of the model, the related generic PDP processes and outputs taken from the above-mentioned survey. The full report contains much more information that is presented here.
There are many reasons why a particular experience may come to the attention of a learner, and these could be roughly categorised as affective, guided or serendipitous.
The content of the experience needs to be captured in some way so that it will be able to be made available to the reflective processes of the learner, as well as to any ICT tools used in conjunction with PDP. This documentation may be done spontaneously, as with a keen diarist, or it could be stimulated or prompted in a number of ways. One way is through the ICT: a system may automatically prompt the learner to record something. Another way is through discussion with another person, maybe one in the helper role.
We have characterised the stage of documenting an experience as being relatively free of theory; but when it comes to recollecting, theory is much more likely to be playing a part. A natural and spontaneous recollection might occur when a person might think, perhaps “ah now, let me see, that reminds me of something that happened last month…”. Or perhaps the person recollecting might be thinking of a series of past experiences. Whichever way it is, some significant association is going on, some connection is being made, and we can imagine the natural theory-building processes as in train.
Once the captured experiences, assumed to be relevant, have been brought back to mind, the stage is set for the learner to form or modify theories which help to explain the significant features of the experiences. From our point of view of personal development, we are most interested in the learner’s theories about aspects of the learner him or herself, which may have affected the experience.
The next step in the model process needs to involve the use of the newly-enhanced personal theory. In general PDP practice, this next step is often setting goals. There are at least two ways in which setting goals is dependent on personal theory. Firstly the goals need to be based on persistent personal theory for them to be acted on consistently. If, instead, goals were based on the feeling of the moment (however induced) they could well never be followed through, as a later checking of feeling against the goal might not fit. Secondly, the personal theories on which the goals are based need to be realistic. If they aren’t, the learner runs the risk either of underachieving, or of overreaching, with consequent failure – which, however, could be used in the next round of personal theory enhancement.
In the survey of PDP practice, there were several other generic activities noted that seem to follow on from the steps of theorizing and goal setting. The common follow-up to goal setting in the PDP context is action planning, which is the detailing of sub-goals and planned activities which are designed to lead to the achievement of the set goal. As with goal setting, action planning uses the enhanced personal theory, this time not just to set appropriate goals, but to select means of achieving those goals that are plausible given that personal theory.
We see actions both as the end result of putting personal theory into practice, and as the raw material from which observations can be made, and things noticed. And acting is an important consideration in PDP as well, where it is sometimes explicitly written in to the programme in terms of developing skills.
The model which above has been outlined in words needs to be formalised sufficiently to represent the structure of a supported PDP process. We present here a UML activity diagram which relates to the model as a whole, and a scenario in three different versions, which can be seen to relate directly to the diagram. Capital letter references in the text refer to the same letters in the diagram.
Figure 1: UML Representation of PDP
The learner is in a work situation, where two colleagues give presentations of their current work to the team. The learner enjoys [A] one of the presentations much more than the other one [D], and asks for copies of the handouts to help later recollection for personal study. That evening, she makes a note in her learning log [H], and annotates this note as relevant to communication and presentation skills.
The following week, knowing that she is going to have to make a presentation in her workplace, she compares her recollections of the two presentations with the last two she gave [L], and looks up the guidelines which are available. She re-assesses the level of her own presentation skills against the guidelines, and makes a judgement of where she is in terms of presentation skill [N].
The learner consults her mentor, who agrees that this is an appropriate issue to focus on at this stage [P], given her imminent presentation task, and a goal is set to improve the presentation style [Q]. She plans appropriate actions to achieve this. The guidelines help her to focus on different aspects of her presentation. Analysing the presentations she has watched and made, she decides to focus on better quality and use of audio-visual aids. She plans her forthcoming presentation [S] referring back to the two presentations she attended recently, analysing them specifically in terms of the quality and use made of audio-visual aids.
The presentation goes well [Z], she appreciates the positive reactions from audience and mentor [A, D] and records this in her log [H]. Because the individual action was anticipated, the recollection that goes on as an integral part of recording [L] is sufficient, without needing any further recollection, for her to know that she can now use audio-visual aids better in presentations [N]. Privately, she knows that whenever another presentation comes up, she will be able to go through the same process with more confidence.
This scenario given above is intended to be naturalistic, and in the form above does not explicitly involve any ICT systems in it operation. It is a plausible, if idealised and stylised, example of a process which should be recognisable by most people involved in helping learners with this kind of skill development, whether in the context of formal education, training or work.
In order to make it directly relevant to the kind of PDP systems that use ICT, we will diverge in two directions: a simple version in which the possible role of an existing ICT system is evident; and a richer version in which more advanced systems are imagined. The base scenario above gives context for the understanding of the simple and richer versions, which are based on the same situation.
The learner is in a work situation, where colleagues give presentations of their current work to the team. The learner enjoys [A] one of the presentations much more than the other one [D]. Towards the end of the day, completing her CPD records, the system she is using guides her [G] for an entry in her learning log [H], and this is enough for her to recollect previous experiences and assess her current level of competence in presentation [N]. In the CPD system, the learner sets a goal to improve her presentation style [Q]. She uses guidelines from the system [R] to plan her forthcoming presentation [S]. (The execution of the plan is omitted, as action is not part of the main model.)
The learner is a student of marketing on a work placement, and two work colleagues are to give presentations of their current work to the team. As the team meeting has been put in the student’s appointments system, as this information is available to her PDP system, and as presentation skills feature in the subject benchmarks for her course, the previous evening the learner is reminded about the presentations, and it is suggested that she attends to various details [C]. The learner recognises one of the presentations as more effective than the other one [D], and asks for copies of the handouts to help later recollection for personal study. That evening, her PDP system reminds the learner [G] to enter reflective notes of the experience in her learning log [H], and to analyse this in terms of its relevance to communication and presentation skills.
The following week, her PDP system has noted the task of making a presentation in her workplace, and reminds the learner at the time she has selected. She uses the system to bring up details and previous reflections on related experiences in the past: the system gives her details of two previous presentations she gave [K, L], including her own analysis of the skills used and the confidence in them at the time, and the written feedback she received from her tutor and peers after those presentations. It is then very easy to find relevant guidelines and study material on presentation skills. Guidelines and principles alongside the recollected experience help her to arrive at her own understanding and conceptualisation of what constitutes effective use of audio-visual support in a presentation, and why. She re-assesses her level against the guidelines, and revises her judgement of where she is in terms of presentation skill [N].
The learner consults her tutor, who agrees that this is an appropriate issue to focus on at this stage [P], given her imminent presentation task, and a goal is agreed to improve her presentation style [Q]; analysing the presentations she has watched and made, she decides on a detailed focus on better quality and use of audio-visual aids. The PDP system contains a number of templates for planning presentations, and she uses one she has not tried before [R]. She completes a new plan for her forthcoming presentation [S] referring back to the two presentations she attended recently, analysing them specifically in terms of the quality and use made of audio-visual aids. She also chooses a short practice task to complete with the help of her peer mentor (or “critical friend”). This is recorded in her appointments system as well as that of her friend.
The PDP system reminds them about the exercise [V], and afterwards offers further opportunity for reflection [C, D, G, H]. The presentation itself goes well [Z]. The learner appreciates the positive reactions from her work colleagues [A, D] and records this in her log [H]. Because the individual action was anticipated, the recollection that goes on as an integral part of recording [L] is sufficient, without needing any further recollection, for her to know that she can now use audio-visual aids better in presentations [N]. Privately, she knows that whenever another presentation comes up, she will be able to go through the same process with more confidence.
Based on the above model, we set out a future architecture for web services in PDP. We considered 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 model building have been 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 as the Personal Information Aggregation and Distribution Service (PIADS), which is used by the PDP web service, but will also be used in other contexts such as within e-portfolios and VLEs.
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.
Figure 2: Components and information flows in the envisaged architecture
Much has been written about the concept of the Personal Learning Environment. We are clear that for the most effective functioning of a PLE, a service to store personal information about learning and related matters (such as a PIADS, introduced below) would be very helpful. A PIADS service would also provide the basis of e-portfolio functionality, and could integrate with tools to manage that functionality (including managing the presentation of records to third parties), which could be implemented in a PLE. Thus, one function of a PLE might be to provide a basic browsing and editing interface to the learner’s PIADS. Additionally, the personal preferences of the learner (as, e.g. IMS AccessForAll [ACCLIP][8]) could be stored in the PIADS, and retrieving these would enable the PLE to configure the user interface to suit the learner’s preferences and needs. Another useful piece of functionality would be for the PLE to act as the front-end to discovery services. Centrally to the current discussion, a PLE could
If the PLE is going to be able to deal properly with LD that is more than just one form, it would also be useful to have some means of storing intermediate results and holding the information for use on other forms, for later submission.
There is no reason why all of anyone’s personal information should be held on one server, and many reasons why it should not be. However, when the person wants to access their information, and control other people’s access to it, it is important that they can have access to all of its parts, in an easily-understood structure. When personal information is created or changed, the learner’s PIADS should be able to direct the information to its proper destination(s) for storage. It should also be pointed out that the underlying learner data may be represented in any format (not necessarily XML). One would expect that the data is transported in ‘standards conforming’ fashion (e.g. XML) but the standard is not necessarily based on an IMS specification.
Having such a service would be a central support for the implementation of e-portfolio systems. A crucial point to bear in mind here is that an e-portfolio not only acts as a personal record and repository, but as a system to expose selected parts of that information to others, either publicly, or by class of person, or by individual. A typical e-portfolio owner may want to keep many personal reflections private; may want to allow, say, all people in a peer group to see contact details and information about group-oriented work; and to show particular CVs to specific people in companies to which the owner is applying for employment.
There should be just one operating PIADS for each learner, which would:
There are services either proposed or under development which aim to do related things – for example,
WS calls to the PIADS need to identify who the subject of the information is, and who is the person or authority making the call. There is a need to authenticate these identities.
Our inclination would be to place PIADS in the Common Services section of the JISC e-learning frameworks building blocks structure[11] and call it something like "personal information management"; this seems to fit with the term "content management". We are unclear as to whether this is actually the same thing as the “filing” component, we suspect not.
The role of the PDPWS is to provide structure and guidance to learners for PDP-related activities – that includes any activity which is to do with transferable skills, and particularly with learning about learning (one aspect of metacognition). Having PDP as a web service enables us to reclaim the established definition of PDP as “a structured and supported process undertaken by an individual to reflect upon their own learning, performance and / or achievement and to plan for their personal, educational and career development”, which says nothing about interaction or storage technologies or systems. With the e-portfolio functionality – to do with storage and management of the information – handled by the PIADS, the role of the PDP service is just to provide the structuring to the process, tailored to the individual. In order to do this, the PDPWS would perform these kinds of function:
Thus, designers of the PDPWS need to design:
This rather abstract definition can be illustrated by comparing it with the LUSID web-based PDP system. The current “where you are in LUSID” is given by the page and the query string (which includes record operated on) and the data store and history. This is quite close in feel, though different in approach.
{Numbers in curly brackets refer to the numbered information flows in Figure 2.}
Say an education provider wants to deliver a short course in Evolutionary Psychology. The main components of this short course might be, say:
We imagine that the level of essay-writing ability in the possible course attendees is not certain, so the educational activity designer wants to add in a brief component on essay planning, which is considered to be in the domain of PDP. The designer could use a discovery service to locate suitable PDP web services. Using a learning design tool, the designer could specify an appropriate activity to help with planning an essay – there may be many of these on offer; metadata should be provided about the activities so that the designer chooses tasks which match learner expectations.
Designers may want to choose between different options for how to specify the one considered best {1}. Firstly, they could simply specify the characteristics of the learners, and choose something at their level: this could be called “anonymous” PDPWS use. Also anonymously, designers could arrange for information about each learner individually to be passed to the PDP system, so that a principled choice could be made of a suitable level of PDP activity. Secondly, they could arrange for a PDP activity that had no immediate relationship to other possible PDP records, but still allow the PDPWS to interrogate appropriate PIADS systems about the characteristics of learners, so that an appropriate level of activity can be served, for classes where there may be mixed levels of personal development: this could be called a “dislocated” PDP activity. Thirdly, there could be “situated” PDP activities, where, for example the designer planned for the learners to review previous essays that the learners had written in the past. Equally, the learners themselves could select an essay planning service from a list, or even take responsibility for searching for a suitable PDP service.
We can envisage the flows of information at “learn-time” in the simpler case where the designer has chosen the essay-planning activity. The learner is registered with the learning provider which is hosting the short course. As part of signing up for the course {2}, the learner allows the course outline schedule to be passed to their PIADS, where it will be available both to their personal calendar system and also to the PDPWS for action planning purposes, as well as later reflection.
The overall Learning Design (LD) instance for the short course is retrieved from the Repository server to the learner’s PLE {3} using a ‘search’ service from the common services layer of the JISC e-learning framework (ELF). (A PDP system would be expected to provide this web service to allow searching.)
Initially, the LD guides the learner to various resources – this is not part of the service to be considered here. Also included in the LD may be some exercises to help and to assess comprehension of the reading material, and also the kind of typically PDP activity that involved metacognition – awareness of the learner’s own learning processes and characteristics. After that, there is a group discussion activity, which is scheduled in the LD, but again delivered through a separate service.
When it is time for the essay planning, the LD provided to the PLE directs the learner to the PDPWS {4}. The PDPWS may interrogate the learner’s PIADS to discover the level of development of the learner both in essay planning and meta-cognitive skills {6, 7}. The LD for the essay planning activity is packaged along with the information needed to specify the essay-planning activity itself {5}, and returned to the learner’s PLE.
The LD then returns to the rest of the course, including the writing of the essay. The essay is sent to the PIADS which stores it in the learner’s e-portfolio {8}, and if appropriate sends it also to the education provider for marking. This may not be necessary if the education provider is able to access the learner’s e-portfolio – all that would be necessary is the essay is made readable by the learner for anyone marking or commenting on it.
Two distinct types of service are needed in this kind of scenario: firstly provision of learning materials and services (provided by the repository and the PDPWS), and secondly storage and management of information (provided by or through the PIADS). They differ in several ways. The learning materials have to be authored, and are liable to require digital rights management of some kind. Learning services may include provision of tutors or other paid advisors or experts as part of the learning process. On the other hand, storage and management of information has neither of these requirements, but it does need to be done independently in principle, because there are other uses of that same information.
The PDPWS call should return IMS LD containing either embedded WS call-backs to the PDP system to fetch the data entry pages, or the data and pages themselves. Ultimately these pages should comply with accepted standards; for example, they could be expressed as xhtml, XForms plus an IMS LIP model. The model combined with the learner’s input data should be sent to a PIADS WS for storage; however, as XForms do not yet support embedded WS calls, this is not currently possible.
The PDPWS must also be usable in contexts other than PLEs, for example, within traditional ‘always on-line’ VLEs. In order that the burden of data management placed on the PLE does not also have to be placed on a VLE, it would seem prudent to offer an alternative online solution. In this case, the LD does NOT contain the XForm plus user data; the form is fetched from the host PDP system on-the-fly and then the data is immediately stored via PIADS when the form has been completed.
As an alternative kind of example, we can look at the scenario envisaged for reflective learning and personal theory building. Learners currently use PDP systems directly for making learning logs, planning, and finding skill development resources. In this future scenario, the PLE would be acting primarily as a front-end to the PDPWS and the PIADS.
Presenting a “chunk” of PDP in this scenario is essentially similar to the previous one. What is different is that here, the learner will not necessarily be directed by an educational designer to a particular activity. In learner-directed PDP, the learner will want to decide what it is time to do now. The reflective personal theory building scenario contains several possible instances of PDP-type activities (or tools):
One very general question to resolve in this learner-directed interaction is how the learner starts off the interaction with the PDP system to get the appropriate activity down from the PDP server, ready to “fill in” and send back.
At present, in LUSID, this can be done in two ways. The learner either follows the path, or chooses from the menu, provided by the system, or looks at the records stored in the system and from that decides what to do. The fact that different pathways suit different learners is reflected in the fact that LUSID “navigational” pages can be constructed, just like all LUSID pages, in a way customised for any particular group of learners. In many cases of learner-directed PDP, there is likely to be a multi-stage interaction dialogue with the learner before a “content” chunk of PDP is ready to be served. The choices to be made in the course of this interaction may be ones for the learner alone, or they may invite a decision process involving other people – mentors or parents for example. The question is then, how is this multi-stage interaction to be carried out with the PDPWS?
There are two issues which may come to the fore in discussing the interaction of a learner with a particular PDP service: the starting point, and the finishing point. The starting point is to answer the question, what is the initial service call that is made to the PDPWS? Is it simply something like “what PDP can you offer me”, or something more detailed? The finishing point is, at what level of granularity is the navigation (or decision about what to do) over, and some substantive PDP activity ready to start?
However, in the case of the starting point question, our intention is to make the PDPWS as accessible as possible at any level, to allow entry either at the top level, or at any other specific place (as in the embedded scenario). So how does a learner search a particular PDPWS for the PDP desired? There are three ways we envisage:
A second point is that the leaf nodes are also arbitrary. It may be possible in many circumstances to package up several pages of PDP activity (including forms such as XForms) into a larger piece of LD, or to have them delivered in separate packages. Putting these two points together, it appears that two variants of just one service call will cover the whole range of PDP web service at learn-time.
PIADS will manage the storage of records; it only makes sense to require it to implement, create, store and delete operations, behind the scenes the service will issue the relevant CRUD operation to the target database. We have not detailed how PIADS manages its aggregation, distribution and synchronisation rules (part of {8, 9}).
This is a straightforward call to get information about an individual learner, either by the learner or by a third party authorised by the learner. The PIADS may need to aggregate information from various sources. Rules about which information is held in what external databases are not passed in the call, but held by the PIADS. One should bear in mind that this call should ideally also serve for e-portfolio use, where the person requesting the information may not be the learner. The learner may want to allow access from some specific systems for some purposes: thus the PIADS needs to know the identity of the requesting system as well.
Parameters:
The response would be an XML instance following the appropriate schema.
The question of where the permissions and authorisation are checked is an implementation detail.
This call is to store information about a learner where it can be retrieved again by the PIADS. The PIADS may distribute any information to the appropriate storage services. (As the XML may differ for different XML specs, a separate call could be used for each different spec: e.g., “storeLIP”, “storeACCLIP”, “storeHRXML”, etc.) The parameters of every call will, however, be the same: the only difference is in the schema which governs the XML document so we feel a generalised approach is best with the type of data to be stored being specified in the WS call.
The parameters will be:
PIADS returns acknowledgement if all information is stored as a status code.
This can also be invoked by the learner or a third party; a third party may have supplied a (read-only) testimonial for the learner.
The parameters will be:
The response can be simply a return of success or failure (status code).
The service should include a facility to create and delete and manage accounts on the target PDP system (for example, “createLearner”, “deleteLearner”). There is also a search service for the learning designer, plus services to return specified PDP processes (as IMS Learning Design and xHTML / xForms).
What is needed is a service to show learning designers the map of all possible “positions” relevant to that PDP service, along with some explanation of what each one is designed to be for. These may be structured hierarchically, or not. The learning designer needs to be able to select any permitted one. The search invocation will be relatively simple: something along the lines of “show me what PDP you offer”.
In contrast to the learner-originated call described later, the designer-originated one will return the complete map of PDP “positions” for that PDPWS, along with metadata describing those positions. As the designers requesting this information are likely to be familiar with Learning Object Meta-data (LOM), the obvious choice is to treat each PDP position as a learning object, and to base the metadata set to use in this context on the UK LOM Core ( http://zope.cetis.ac.uk/profiles/uklomcore ). The UK LOM Core information model, along with many other similar metadata models, has a section (7, “Relation”) dealing with relationships between leaning objects. This can be used to define the hierarchical structure, if appropriate for a particular PDPWS, using the Dublin Core relations “ispartof” and “haspart”.
In summary, we are saying that a PDP system must support some sort of simple search service – the interface for this will be defined as part of the ELF common services layer (see http://www.elframework.org/framework/).
This service is called as the learner interacts with their VLE or other on-line e-learning system.
The call may have been placed at a strategic point in the learning environment by the learning designer or tutor. Typically, the learner will click on a link or button to initiate the process; the result will be that control is passed to a learning design player which then will execute the LD that is returned as a response to the service invocation. Parameters:
Initially, no focal record or other parameters need to be supplied, and the PDPWS returns a default menu for that learner, as designed and determined by the designers of the PDPWS. As discussed above, that default menu may have one or more of: a search box in which to enter keywords; the top level of a hierarchical menu system; or a fully-displayed structure of nested lists to choose from. Later parameters are provided by the PDPWS itself, during the course of usage.
The last parameter – a set of properties – is a mechanism for the PDP system to be passed implementation-specific information. This list may include the "position" in that PDP system (which may be multi-dimensional); values may be chosen by the learning designer, or filled in by the learner during running of the system. Examples of learner-centred values include focal date and time span – these could be used when planning activities by the use of a Gantt chart – the system needs to know what time frame to use for the chart. Any parameters at all can be passed by this method.
If a “position” is supplied, it would depend entirely on the map of the PDP provided (see 3.5 below). For instance, in LUSID, one possible position could be of analysing the skills used in a particular experience. The corresponding “focal” record would refer to the experience being analysed. In this case, working on one specific record, that record ID can be given. But it is less clear how to specify the records more generally. Typically, working on one record will involve reviewing related records, in a fairly predictable manner. Perhaps ideally, the PDPWS would be able to work out, from the position and the central record, which other records were appropriate – these would in any case be included in the XForms. If they stood to be edited in the activity, they would also appear in the XForms model, presumably as LIP.
The PDPWS returns a piece of LD with embedded web service requests for at least one ‘user input’ form. This LD represents a PDP process to be followed by the learner.
The LD is designed to take the particular learner (category of learner) either through the next decision process, or through the actual PDP activity (the “leaf”). In many cases, the LD component could be a content-free wrapper, meaning “take this form and do it now”. But in other cases, any decision process could for instance be prefaced by a discussion with parent / teacher / tutor / mentor, which can be scripted with the LD. Thus there is no hard-and-fast distinction between navigation and “proper” PDP. Every action can potentially be seen as a process, and it is the job of the LD to coordinate any different actors and scenes in that process.
This will be invoked from within the LD returned by the “getPDPInteractive” service call. To construct the PDR input form, the PDP system will have to retrieve the form template and then contact the learner’s PIADS to retrieve the appropriate data which will be folded into the form before it is despatched to the user.
Parameters:
The XForm should hold embedded web service calls to PIADS which it would send standards compliant data to so it can be stored; in the short term this is not possible (as XForms do not support WS calls), so an alternative method could be used.
This is the service that would be used with a PLE. It is essentially the same as “getPDPInteractive” except that all required elements, including learner data, are contained in the Content Package. The package will include all IMS LD, plus all data entry forms plus the user data relevant to those forms as it was when the package was assembled. As mentioned elsewhere, the burden of managing the package is placed on the PLE which will also have to ensure that the PIADS are updated when the learner has finished.
Here we could sketch out what happens, in the terms above, for some of the “positions” in our model of Personal Theory Building (see above) were it to use such a PDPWS.
This refers to the documenting stage. This is where a journal or log entry is made about the reactions to the work presentations. In the UML diagram presented earlier, the steps are (C) – D – G – H.
The learner sets up the learning log just once, not at every interaction. If the log is to be completed regularly, the PLE could prompt the learner. Otherwise, the learner enters spontaneously, through a series of menus, and chooses the log. The PDPWS sends the log form. The learner fills in log form and submits the form. The log information goes to the PIADS. The PDPWS offers some other activity which might be appropriate. If the learner declines, the interaction is then closed.
This is represented in the recollection and theorising steps. In the UML diagram, the steps are (K – L) – N.
The learner, as before, starts the PDPWS and goes through menu steps until the skill area is chosen; requests the activity to review level of confidence in a particular skill area, which may be smaller or larger.
The PDPWS sends a form or forms with all the relevant records displayed, and a form for revising the new level of confidence. These may be articulated by the LD, for instance so that a sequence of evidence is gone through in a particular order; or that such a choice is given to the learner.
The learner goes through the LD activity, at the end reaching a form which ends the activity, submits the information to the PIADS, and may select a new position from the PDPWS – for example, the setting goals step which follows here.
This is steps P – Q in UML activity diagram.
The learner navigates through to the activity of setting a new goal. The PDPWS returns some LD which specifies that the goal setting must start with a discussion with the learner’s mentor. (How this might be implemented is out of scope here.)
After that has finished, the learner fills in a form for the new goal. Submission stores the new goal in the PIADS and sends a message to the mentor about where to find it. The mentor adds a note to the goal. The PDPWS may suggest supplementary questions to the learner.
This is part of the action planning step described above. The UML diagram steps are R – S.
The learner uses the PDPWS (or the PIADS directly) to navigate through records to a particular goal – at that point, the WS call will have the ID of that goal as the focal record. Having identified the goal, the PDPWS could check that the goal and other records were set as visible by the advisor, and then return an activity involve a learning advisor also being sent a form with the goal and plan details, and perhaps opening a collaborative facility such as voice or screen chat at the same time.
This relates to the embedded PDP scenario already described above. Let us revisit this as a stand-alone PDP activity
The learner starts up PDP from the PLE and navigates through the choices provided by the PDPWS until reaching an option for planning an essay. (We assume this is provided in the PDPWS, though there is no reason why any particular activity should be provided.) At each point, the PDPWS requests any information that is required from the PIADS, in order to properly shape the choice activities (often just menus).
The last choice is of a number of different advanced essay types. The learner chooses a natural science essay. The PDPWS has no more need to consult with the PIADS at this stage (except perhaps to check everything is still in order) and then returns to the PLE a structured natural science essay-planning activity. This has several forms, linked with the LD structure. At the end of the essay planning activity, the output from the forms is collected together and sent as a LIP file to the PIADS for storage.
If the PDPWS is acting in a truly stateless way, there will be no need to inform the PDPWS that the learner has finished with PDP for the moment.
The recommendations for a PDP WS interface made here have been implemented as a Java-based open source software development kit (SDK) to help others in deploying the services[12]. Many of the services defined therein have been implemented using LUSID.
Further details are available on the project website[13].
The authors wish to thank Tunde Varga-Atkins from the University of Liverpool for help with Learning Design; John Harrison from PIB-d Ltd for useful discussions and comments regarding PIADS and Virtual Home; and Professor Bill Olivier of the IEC, University of Bolton for useful information regarding IMS Learning Design.