Just-in-time generation of pedagogically sound, context sensitive personalized learning experiences.
In the past, Adaptive Hypermedia Systems (AHS, [Brusilovsky, 2001]) have attempted to customize courses to a learner's prior knowledge (Kayama & Okamoto, 1998), goals (Vassileva, 1996) and personal preferences (Specht & Oppermann, 1998) without taking into consideration any form of pedagogy. As a result, such systems neglect the entire body of research that exists in the educational field and fail to take advantage of the benefits that the application of pedagogy has for the learning experience (Conlan & Wade, 2004). iClass (iClass, 2004) is an open learning system which utilizes pedagogical strategies to adapt to learners' needs, both intelligently and cognitively. This article describes the LO Generator and Selector services, which facilitate the delivery of customized learning experiences as part of iClass. The Selector Service is responsible for building a personalized path for a learner through a knowledge domain, consisting of concepts. This is carried out in accordance with the learner's objectives and preferences while also taking into account the preferences of the teacher involved. Specifically, the teacher's preferences allow him/her to scope the boundaries and the extent to which the personalization of the learning experience will occur, thus providing the teacher with control over the iClass system and the manner in which it carries out personalization. The Selector Service will approach the production of a personalized learning path by applying a sound pedagogy. This approach will be similar to that taken by systems such as APeLS (Conlan, Wade, Bruen, Gargan, 2002) and WINDS (Kravcik & Specht, 2004) to produce complete courses. APeLS is an AHS that employs the Multi-Model, Metadata driven approach (Conlan, 2005), in other words APeLS maintains a set of models describing the necessary learner, content and pedagogical information, which the system can then reconcile, at runtime, to generate a personalized course for an individual learner. The key advantage of APeLS is the separation of pedagogy from the adaptive system as opposed to systems such as AHA! (De Bra & Calvi, 98) and ELM-ART (Brusilovsky, Schwarz, & Weber, 1996), which generally embed the models/rules in the engine. This provides APeLS with the flexibility to use many different pedagogical strategies.
Unlike APeLS, the design of the Selector Service separates pedagogy and the description of the knowledge domain into two distinct entities. The knowledge domain is described in terms of an ontology, which describes the skills, concepts, facts, and so forth. that make up the domain as well as the relationships between them. The knowledge domain is described in a pedagogically neutral manner emphasizing its separation from any description of pedagogy. The pedagogical neutrality of the knowledge domain ontology helps to reduce biases towards a particular approach to teaching/learning, thus enabling the successful application of different pedagogies to the knowledge domain. Pedagogies are encapsulated in Pedagogical Strategies; these are sets of rules that determine the approach to be taken in order to present a concept as part of a pedagogically based course. A Pedagogical Strategy should be considered as a high level guidance that may be applied to concepts or subconcepts and which is selected based on the preferences of both the teacher and the learner. Through the accommodation of both teacher and learner preferences in the selection of a pedagogical strategy, the personalized course produced should fit both the teacher's preferred mode of teaching and the learner's preferred mode of learning.
The separation of pedagogy and concept domain brings several significant benefits; it speeds up the time taken to develop courseware, reduces the cost of development and also introduces a new axis of adaptivity upon which adaptation/personalization can occur. The time and cost reductions are brought about because pedagogies can be developed independently of knowledge domains and vice versa. For example, a course developer (knowledge domain expert) need not have any specialist knowledge of the pedagogical strategies that may be applied to the knowledge domain they are developing. Further reductions in the expense of creating personalized educational courseware come from the ability to reuse any preexisting pedagogical strategy or domain ontology. Improved personalization is realised through the application of many different pedagogical strategies to the same concept domain. This means that it is possible to adaptively select the most appropriate pedagogical strategy for a specific learner, irrespective of what they are learning, which will enhance his/her learning experience.
The learning path produced by the Selector is only half of the "story." To present the learning experience to a learner, the concepts contained in the learning path need to be associated with learning objects. As part of iClass, the LO Generator aims to provide pedagogically sound, personalized, and context sensitive learning objects. The function of the LO Generator is to select the most appropriate learning content from the learning object space, which corresponds to the specific needs of the Selector. The LO Generator interacts with various distributed information repositories, using a variety of metadata formats and ontologies, to assemble appropriate LOs that facilitate the teaching of each concept in a learning path in a manner that is appropriate to the learning preferences of the learner. It is the role of the LO Generator to select or create appropriate learning objects to instantiate the pedagogically influenced concepts in the PLP. The LO Generator also accounts for learner and contextual preferences selecting or generating learning objects. In summary, the Selector guides the overall pedagogical strategy of the learning experience, while the LO Generator personalizes towards the learner's preferences and current context.
This article describes the workflow between the Selector and LO Generator services and describes the just-in-time generation of pedagogically sound, context sensitive personalized learning objects, which are based on personalized learning paths. The next section describes the reconciliation of multiple models towards the creation of a personalized learning path. The following section "Producing Personalized Learning Objects," details how appropriate personalized learning objects are created/selected for this personalized learning path. Then a section describes a worked example of how personalized learning objects are produced, followed by a section that describes the standards and specifications most relevant to the Selector and LO Generator; and then a section highlights how the Selector and LO Generator cooperate with other services in the iClass framework to achieve personalized experiences. Finally, is the section that concludes the article.
RECONCILIATION TOWARDS PERSONALIZED PATHS
The role of the Selector, within the iClass framework, is to produce a Personalized Learning Path or PLP. The aim of a PLP is to allow the learner to obtain a skill or set of skills through his/her engagement in activities as part of a pedagogically sound learning experience. The PLP itself is a structured sequence of concepts that is dynamically generated based on a set of requirements. Each concept in a PLP is associated with a type of learning activity as well as being related to a specific skill. A key aspect of the PLP generation process is the personalization of the PLP towards an individual learner to support and enhance the learning experience.
As iClass is a tool to be used within the context of a classroom, it is important that any PLP produced by the Selector should be appropriate for use within that environment. As such, the Selector must take account of the requirements of the teacher in conjunction with accepted pedagogical best practice as well as the needs of the learner. Figure 1 illustrates how the Selector allows all of its stakeholders to influence the generation of a PLP through the models that it uses.
Each of the models consumed by the Selector provides it with information as follows:
Teacher model. Provides details of the skills which a teacher wishes learners to attain within a given Concept Domain. This model also allows the teacher to influence the selection of Pedagogical Strategies by the Selector.
Learner model. Provides information about the learner's competencies/prior knowledge as well as details of any learning biases, and so forth, that a learner might have.
Concept domain ontology. A pedagogically neutral representation of a subject domain including the appropriate semantic relationships between skills and concepts. It acts as a "map" that allows the Selector to generate paths through the subject domain.
Pedagogical strategy. An expression of how pedagogy may be used to influence the creation of a PLP. The strategy will provide the Selector with a description of how concepts should be manipulated and arranged so that they fit into a given pedagogy.
To better understand how the Selector can reconcile all of these models to produce a PLP it is necessary to understand the Selector's workflow. When the Selector is invoked, it first identifies the appropriate Concept Domain Ontology. This provides the Selector with the contextual information necessary for it to interpret both the Learner and Teacher Models, which are retrieved next from their respective repositories. Following this, it is necessary for the Selector to retrieve an appropriate Pedagogical Strategy; this selection can be influenced by both the Teacher and Learner Models. It is possible for the teacher to explicitly state that a specific pedagogy be applied or alternatively this decision can be left to the Selector which will then base the selection of a Pedagogical Strategy on the characteristics of the learner. In the latter case, the Selector will choose a pedagogy that is most appropriate for the individual learner.
[FIGURE 1 OMITTED]
At this point the Selector has retrieved all of the models necessary for the creation of a PLP. The next step in the process is to identify the set of skills which the PLP should cover. This is a two stage process consisting of first removing any skills which have already been attained by the learner and secondly adding any prerequisite skills that the learner does not yet have. Skills that have already been attained are identified by comparing the skills listed in the teacher model with the competencies defined in the Learner Model. Necessary prerequisite skills are identified through the use of the concept domain ontology to first find prerequisites and then, as before, comparing the prerequisite skills with the competencies of the learner. This is an iterative process which continues until a point is reached at which the learner has the appropriate skills to being learning.
Once a complete set of skills has been built, the equivalent set of concepts is generated through the use of the concept domain ontology, which contains the relationships between skills and concepts. The final stage in the production of a PLP is to generate the PLP structure based on the selected Pedagogical Strategy and to populate that structure with concepts and their associated activity types. The activity type can be defined by the teacher in the Teacher Model or can be selected by the Selector is a similar way to the selection of the pedagogical strategy.
As the Selector populates the PLP with concepts it "validates" each concept with the LO Generator. This validation ensures that the Selector does not include a concept, activity pair in the PLP which the LO Generator could not produce an appropriate Learning Object for. If a concept, activity pair is invalidated by the LO Generator, the Selector will have to rework the PLP, but this should rarely happen. The process involved in validation and the creation of new learning objects by the LO Generator will be discussed in the following section.
PRODUCING PERSONALIZED LEARNING OBJECTS
The role of the LO Generator, within the scope of the iClass project, is to provide an appropriate learning object (LO), which can be presented to a Learner, as well as to provide an identifier for each LO to the Selector during its generation of a PLP, as described in the previous section. This process may be as simple as selecting an appropriate preexisting LO and returning its identifier. If an appropriate LO does not already exist, the LO Generator may be able to "morph" a preexisting LO into one which is more appropriate. Alternatively, if this is not possible, the LO Generator must create a completely new LO. These learning objects are adaptively tailored towards the preferences of an individual learner as well as his/her competencies within the given knowledge domain.
The LO Generator makes use of the Learner Model to obtain information about the pedagogical preferences of the learner and also to get information about his/her prior knowledge. Information from the repository of contextual data, which stores information about environment, device type, and so forth, is also accessed. An important repository with which the LO Generator communicates is the actual learning object space, which provides access to the metadata associated with the content needed for the generated learning object. This metadata represents atomic level SCOs (SCORM, 2000), which are not necessarily educationally complete, but when combined together with other SCOs can be formed into coherent LOs. The importance of maintaining separation between the pedagogy, the knowledge domain ontology and the content stems from the need to make maximum use of each of these elements through reuse (Dagger et al., 2003). This separation also provides the ability to replace any of these aspects when necessary (Figure 2).
When the LO Generator is asked to validate a concept by the Selector, it is given the appropriate information to fulfill this task. The validation step is necessary as it ensures that the concepts and activities added to a PLP by the Selector can be realized by the LO Generator. This iterative process, carried out for each concept/activity pair added to a PLP, guarantees that the PLP can be populated with appropriate LOs at execution time. As inputs, the LO Generator is given a learner identifier, a concept or set of concepts, and also the relevant activity. Based on the concept(s) and the activity, the LO Generator determines whether an appropriate LO can be chosen or created from existing SCOs.
[FIGURE 2 OMITTED]
The initial step involved in the process of validation is to get the information from the Learner Model which will be necessary for the personalization of the learning object. This information includes the preferences of the learner as well as his/her prior knowledge on the given concept. This information can be obtained from the Profiler and Monitor services within the iClass system.
The behavior of the LO Generator depends on the selection of a relevant pedagogical scenario which dictates the steps that will be undertaken by the service to reconcile the concept(s) and activities into real LOs. These scenarios, characterized as narratives, can be chosen adaptively based on the preferences of the learner that the content is being adapted to. These scenarios interpret the preferences and provide criteria for searching the learning object space for suitable SCOs or LOs.
Where an appropriate LO is available that requires no modification, its unique identifier is returned to the Selector. When simple changes are necessary, the modifications are implemented, the new LO is added to the learning object space and the new identifier is returned to the Selector. This LO is added to the learning object space as a metadata manifest describing the new LO and its re-sequenced/modified SCOs. If an existing LO does not exist and it is not possible to alter an existing LO to satisfy the requirements, a new LO must be created. This creation is also executed by the appropriate selection of a pedagogical scenario. These scenarios will guide what type of SCOs should be sequenced together based on the preferences of the learner, these will be aimed at the concept(s) and activity supplied by the Selector service, and will be based on the relevant concept domain ontology that the concept(s) belong to. The first step in the process involved in the production of a new LO is to select an appropriate pedagogical scenario. This is done by reconciling the concept/activity pair that the new LO is to cover, the learning preferences of the learner and the metadata describing the different pedagogical scenarios available. The pedagogical scenario will describe the types of SCOs that should be assembled together to fulfill the concept/activity requirement of the Selector. During the assembly process the pedagogical scenario will also describe how learner preferences should be accounted for, thus helping to refine SCO selection and assembly. Once the new LO is assembled a manifest describing its structure and the sequence of SCOs is uploaded to the learning object space and the identifier is returned to the Selector.
WORKED USE CASE
In the example of a case study, it is necessary for the Selector to restructure the concepts in a manner such that the structure of the concepts reflects the format of a case study. A generic case study might be broken up into the following parts: an introduction to the topic, contextual information, a problem statement, support/framework for solving the problem and an evaluation of the solution. In this scenario, the Selector would have to take the concept(s) and break them up, duplicate them or otherwise manipulate them so that each of the sections of the case study included the appropriate concepts.
For example, if a case based approach was applied to set of physics concepts the PLP may include introduce Newton's Third Law, present the problem of colliding objects, and so forth. In this case, introduce and present problem are elements of a pedagogical strategy. Figure 3, shows the interactions primarily between the Selector and LO Generator and their repositories. This section describes the workflow between the Selector, LO Generator and Presenter to produce a personalized learning experience.
When using the iClass system to create learning episodes, teachers are given the option of specifying the scope of the course across an existing knowledge domain and to specify the required learning outcomes for the course. At this point, the Selector service interprets this teacher information, along with the available learner information to produce a subset of the knowledge domain. A pedagogical strategy is then selected by the Selector, also based on learner and teacher preferences. In our example, the concept domain is Physics and the subdomain is Newton's Third Law and the chosen pedagogical strategy selected by the Selector service is a case-study, which introduces a concept, presents a problem statement, provides resources to the learner and may provide an example solution.
The pedagogical strategy and the subdomain are reconciled together by the Selector to create a narrative or Personalized Learning Path that consists of concepts and the pedagogical relationship between them. The prior knowledge of the learner will have to be taken into account at this stage; it makes no sense to describe something to the learner that they already know. Furthermore, it is also ineffective to present concepts which the learner does not yet have the prerequisite knowledge to understand. Using the pedagogical strategy, the Selector may specify that the first LO in this PLP will introduce Forces. In this case introduce is an activity in the pedagogical strategy being employed and Forces is the concept it is being applied to.
[FIGURE 3 OMITTED]
After specifying the first concept, the Selector makes a request to the LO Generator to check and see whether that concept exists in the learning object space, which is shown as step 1 in Figure 3. The LO Generator then assembles information about the learner. This information differs from that which the Selector used as it relates primarily to the presentation of the LO. In this case, for example, the learner prefers visual instruction (the use of diagrams, etc.), other relevant contextual information utilized by the LO Generator might including the fact that, for example, the learner in our use case is using a black and white display PDA to access the course (Brady, Conlan, & Wade, 2004).
Using these additional parameters, the LO Generator now conducts a search of the learning object space (provided by the Content Access Service (CAS) in iClass) to look for learning assets that can be combined to fulfill all of these requirements. Upon receiving the metadata information from the learning object space, shown in step 2 of Figure 3, the LO Generator returns one of two possible results to the Selector service (a) the LO does not exist and no variation can be generated, or (b), it returns the LO identifier for either a modified LO or a newly created LO. In this case, an LO exists that satisfies the pedagogical strategy and the visual preferences of the learner. To fill the contextual needs, in this case the screen limitations of the device, the LO will have to be "morphed," so the LO Generator sends back a return call citing option (b) above. The LO Generator creates a skeleton of this morphed or new LO, adds it to the learning object space (step 3 in Figure 3), and returns the LO identifier to the Selector (step 4 Figure 3). The skeleton LO created will be used at run time to create a complete LO containing content assets.
After confirmation from the LO Generator, the Selector proceeds onto the next step in the pedagogical strategy, which is to state Newton's Third Law, and the cycle begins again, stepping onto the definition of the law, examples that illustrate the law, and a quick test to see if the learner understood the law. At the end of this, a full Personalized Learning Path (PLP) exists for teaching this concept to this learner through this concept domain.
The LO Generator has several options available to it to deal with the PLP. In the first case, a new service available in iClass needs to be introduced, the Presenter service, which will allow for just-in-time generation of personalized LOs. The Presenter is a service that can interpret the PLP and present the navigation embodied within the PLP. It invokes the Selector in the first place, and after the Selector has finished it returns a PLP identifier to the Presenter, which can be seen in step 5 of Figure 3. Using this PLP identifier the Presenter can query the CAS for the relevant PLP. Embedded in the PLP will be several LO identifiers and, again, the Presenter can query the learning object space to get back the appropriate LOs (step 6 in Figure 3). Another option which will be available in the LO Generator service will be the possibility to deliver a complete content package with the personalized LOs and the IMS Learning Design (IMS LD) to govern their delivery. For the PLP to be effective, the LO Generator must fulfill all of the required aspects of the scenario or strategy embedded in it.
THE ICLASS FRAMEWORK
The iClass system consists of a framework of services that support all the major stakeholders in the provision of eLearning in a structured educational environment. These stakeholders include the learners, teachers, parents, school administrators, and legacy learning management system (LMS) vendors.
As services within the iClass framework (Turker, Gorgun, & Conlan, 2006), both the Selector and the LO Generator must interact with the other available services to carry out their respective tasks.
Figure 4, illustrates the relationships between the Selector, LO Generator and the iClass services which they depend on. From the point of view of the Selector and LO Generator, the other services can be considered as either producers or consumers. The Teacher Preference Tool, which provides the teacher with the control over the iClass system mentioned previously, is a consumer of the Selector. The Presenter, as the Learner interface to iClass, consumes both the Selector and the LO Generator, which in turn is consumed by the Selector as part of the validation process. As shown, the Learner Model discussed previously as a data source for both the Selector and LO Generator are obtained from the Profiler and Monitor (Muehlenbrock, 2006) services. It is necessary to query both of these services in order to build a complete model of the learner as both services track different aspects of the learner. The Profiler supplies data about the learner's preference and portfolio details, while the Monitor is responsible for tracking the learner's competencies (prior knowledge) in a given skill. The information about the Learner captured by the Profiler and Monitor is complemented by further information that is provided by the Learner through the Student Preference Tool. Unlike the learner information, the Teacher Model, which is produced by the Teacher through their use of the Teacher Preference Tool, is stored in the Profiler alone. The other models needed by the Selector and LO Generator are the pedagogical model and the knowledge domain ontology as well as the metadata models from the learning object space. All of these models are stored in the Content Access Service (CAS) (Turker et al., 2006) and can be retrieved using the SQI (Massart, 2006) interface which the CAS implements.
[FIGURE 4 OMITTED]
The CAS is also utilized by the Selector and the LO Generator in order to store the PLPs and LOs produced by the services respectively. When this occurs the CAS provides a globally unique identifier for the resource being uploaded. This can then be used by other services, primarily the Presenter, to retrieve necessary PLPs or LOs.
RELEVANT STANDARDS AND SPECIFICATIONS
As the iClass framework consists of many different services developed by different members of the iClass consortium, the interoperation of these services is an important consideration, as is interoperability with a broader set of eLearning services. One step that has been taken to facilitate this interoperation is the adoption of open standards and specifications. Another advantage associated with the use of open standards and specifications is improved communication between the partners in the consortium due to the common terminology they provide.
In the case of the Selector and LO Generator services, all of the models that they utilize, as well as their outputs, will be based on the relevant open standards. It is intended that the Knowledge Domain Ontology will be based on the W3C's OWL Web Ontology Language Recommendation (McGuinness & van Harmelen, 2004). OWL is intended to be used in cases where the meaning of terms and the relationships between them need to be processed by an application. The advantages of using OWL for the Knowledge Domain Ontology are that it is very expressive in terms of describing concepts as well as relationships; it also supports properties such as cardinality and equality. There also exist many tools that can be used in creating OWL ontologies. The PLP produced by the Selector will be based on the IMS Learning Design Specification (IMS, 2003). Learning Design (LD) is a framework that describes the workflow of the teaching/learning process while supporting different kinds of pedagogical models and the personalization of learning activities (Koper, 2004). LD does not restrict the use of pedagogies by prescribing a specific set of pedagogies, as the Selector will make use of many different Pedagogical Strategies which makes LD a suitable basis for the description of a PLP LD also supports blended learning, that is, the use of nondigital learning resources within the learning experience, this too is a feature of the iClass framework. LD will also facilitate the inclusion of decision points within the PLP (rules that are resolved at run time depending on the value of a property within the Learning Design). It is envisaged that decision points within the PLP will allow for dynamic adaptation towards the learner at run time. For example, the path taken by student might change depending on the result of a quiz that the student takes. This information could not be known when the PLP is being generated and so the decision point is left in the PLP to be resolved later. In the case of the LO Generator, its output will be in the form of IMS content packages with the relevant LDs and metadata included.
This article has described the workflow between the Selector and LO Generator services of iClass and described the just-in-time generation of pedagogically sound, context sensitive, personalized learning experiences. The Selector and LO Generator services described in this article are key elements of the iClass vision. The benefits of applying appropriate and sound pedagogy to a learning experience have been shown to improve the performance of the learner. In many existing AHS a "one size fits all" approach is often taken to pedagogy. Such an approach cannot hope to address the needs of all learners, nor does it integrate well with every teacher's teaching methods. Enabling the teacher to personalize the pedagogical strategy applied to a course towards his/her own needs will allow the teacher to better integrate eLearning with his/her traditional classroom teaching. An added benefit of adaptive pedagogical strategies is that it gives the teacher the ability to tailor the delivery of a course towards an individual student's needs. This can be advantageous if a student is not responding well to the traditional pedagogical approach to a subject domain and where they might benefit from an alternative strategy.
The iClass IST project, funded under the European Commissions 6th Framework, is striving to provide educators and learners with a personalized learning environment built using pedagogically sound principles.
Brady, A., Conlan, O., & Wade, V. (2004, November). Dynamic composition and personalization of PDA-based eLearning--Personalized mLearning. Proceedings of E-Learn 2004, World Conference on E-Learning in Corporate, Government, Healthcare and Higher Education, (pp. 234-242), Washington, DC.
Brusilovsky, P. (2001). Adaptive hypermedia. In A. Kobsa (Ed.), User Modeling and User Adapted Interaction, Ten Year Anniversary Issue, 11(1/2), 87-110.
Brusilovsky, P., Schwarz, E., & Weber, G. (1996). ELM-ART: An intelligent tutoring system on the World Wide Web. In Proceedings of the Third International Conference, ITS, 1996.
Conlan, O. (2005). The multi-model, metadata driven approach to personalised eLearning services. Unpublished doctoral dissertation University of Dublin, Trinity College.
Conlan, O., & Wade, V. (2004). Evaluating the multi-model, metadata-driven approach to producing adaptive eLearning services. Proceedings of the Third International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems (AH2004) Eindhoven, The Netherlands.
Conlan, O., Wade, V., Bruen, C., & Gargan, M. (2002, May). Multi-model, metadata driven approach to adaptive hypermedia services for personalized eLearning. Proceedings of the Second International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems, Malaga, Spain.
Dagger, D., Conlan, O., & Wade, W. (2003). An architecture for candidacy in adaptive eLearning systems to facilitate the reuse of learning resources. Proceedings of E-Learn 2003, World Conference on E-Learning in Corporate, Government, Healthcare and Higher Education, Phoenix, AZ.
De Bra, P., & Calvi, L. (1998). AHA: A generic adaptive hypermedia system. In Proceedings of the 2nd Workshop on Adaptive Hypertext and Hypermedia, (pp. 5-12), Pittsburgh, PA. (Proceedings available as CSN 98-12, TUE, or Retrieved October 3, 2005, from http://wwwis.win.tue.nl/ah98/DeBra.html)
iClass Integrated Project, Annex 1, Description of Work (2004). Retrieved October 3, 2005, from http://www.iclass.info
IMS Global Learning Consortium, Inc. (2003). IMS global learning consortium: IMS learning design specification. Retrieved October 3, 2005, from http://www.imsglobal.org/learningdesign/
Kayama, M., & Okamoto, T. (1998). A mechanism for knowledge-navigation in hyperspace with neural networks to support exploring activities. Proceedings of Workshop "Current Trends and Applications of Artificial Intelligence in Education" at the 4th World Congress on Expert Systems (pp. 41-48), Mexico City, Mexico.
Koper, R. (2004). IMS learning design: What it is & update on current activities. Proceedings of Unfold and Surf Six Joint Meeting, Heerlen, The Netherlands.
Kravcik, M., & Specht, M. (2004) Flexible Navigation Support in the WINDS Learning Environments. In P. De Bra & W. Nejdl (Eds.), Proceedings of the Third International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems (AH2004), LNCS 3137, 156-165.
Massart, D. (2006) Accessing learning contents using a "simple query interface" adapter. International Journal on E-Learning, 5(1).
McGuinness, D.L., & van Harmelen, F. (2004, February). OWL web ontology language overview. W3C Recommendation.
Muehlenbrock, M. (2006). Learning group formation based on learner profile and context. International Journal on E-Learning, 5(1).
Sharable Content Object Reference Model (SCORM, 2000). Retrieved October 3, 2005, from http://www.adlnet.org/
Specht, M., & Oppermann, R. (1998). ACE--adaptive courseware environment. The New Review of Hypermedia and Multimedia 4, 141-161.
Turker, A., Gorgun, & Conlan, O. (2006). The challenge of content creation to facilitate personalized eLearning experiences. International Journal on E-Learning, 5(1).
Vassileva, J. (1996). A task-centered approach for user modeling in a hypermedia office documentation system. In P. Brusilovsky & J. Vassileva (Eds.), Special Issue on Adaptive Hypertext and Hypermedia, User Modeling and User-Adapted Interaction, 6(2-3), 185-223.
IAN O'KEEFFE, AOIFE BRADY, OWEN CONLAN, AND VINCENT WADE
Trinity College--Dublin, Ireland
|Printer friendly Cite/link Email Feedback|
|Publication:||International Journal on E-Learning|
|Date:||Jan 1, 2006|
|Previous Article:||Progressive inquiry learning object templates (PILOT).|
|Next Article:||Towards next generation activity-based learning systems.|