P Contreras

F Murtagh
email: fmurtagh@acm.org

AstroGrid as an e-Learning Environment

Keywords: AstroGrid, grid computing, collaborative work, e-Learning

We present the concept of the Virtual Observatory through the AstroGrid project, which is a Virtual Organization making intensive use of the Internet to produce a working data-grid for Astronomical applications. AstroGrid has implemented a series of tools which facilitate collaborative work such as news, forum and discussion pages, all of them inspired by the open source and licensing philosophy. Additionally we explore how such an Astronomical Grid project can be used in the future as an e-Learning service platform and as a tool for a much wider audience than researchers and astronomers, such as students and the wider public interested in this area.

INTRODUCTION

The terminology "Grid Computing" has been widely adopted in reference to the use of distributed computer resources across a network, working in a coordinated way, and sharing not just information but its processor cycles.

Grid technology is applied in a number of scientific areas, from climate simulation to finance and astronomy just to name a few. In order to archieve these different Grid networks a series of guidelines, standards and protocols are needed, and a range of working group such as those affiliated to the Global Grid Forum [START_REF] Forum | Global Grid Forum[END_REF] have been established.

The astronomical area is no exception to this trend: astronomers and computer scientists are working to ensure standards for a data-grid platform. This context is where AstroGrid is playing an important role.

The paper is structured as follows: firstly we present AstroGrid and its relationship with the Virtual Observatory, and secondly the AstroGrid collaborative environment and its architecture is shown. The final section explores e-Learning scenarios for AstroGrid and e-Learning architectures for the Virtual Observatory.

ASTROGRID AND THE VIRTUAL OBSERVATORY

AstroGrid [START_REF]Astrogrid portal[END_REF] is a $10 million project aiming to produce more economic, faster and effective astronomy through the generation of open standards and interfaces. The AstroGrid framework helps to enable different data centres across the United Kingdom to publish services and data into a data-grid infrastructure accessible on the Web. Such a framework also makes it easier for the different astronomical data centres to interact; it offers a wide range of analysis and visualisation tools through a common interface.

AstroGrid is not alone in its attempt to standardise access to astronomy information. It is part of a worldwide effort to transform astronomical data repositories into a world Virtual Observatory (VO), an organisation of which it is also a founding member. Such an initiative is led by the International Virtual Observatory Alliance [START_REF]International Virtual Observatory Alliance[END_REF] (IVOA) movement, which consists of around sixteen active international members.

AstroGrid itself can be considered as a Virtual Organisation, with its members working in institutions across the United Kingdom. To achieve its goals AstroGrid bases its work on collaboration, and most of its generated information, including almost all aspects of its work processes, is open to the public and accessible over the Internet.

The following section describes the collaborative approach taken in the development of the AstroGrid project -the so-called extreme programming software engineering model based on continuous rapid prototyping and code integration.

ASTROGRID DEVELOPMENT PROCESS AND COLLABORATIVE WORK

The AstroGrid philosophy is one of an open collaboration of researchers and technologists. To allow these people to work in partnership effectively, a range of web-based tools is required. In such a collaborative software development project there are different obstacles to overcome before the collaborative development can become effective. Firstly, good communication is essential in many aspects. Developers need to be aware of information regarding the project as a whole, information regarding specific sections, and they need to be able to directly communicate with other developers. The latter is of high importance in the AstroGrid case. Developers working within the project are assigned tasks in so-called development cycles which are specified by astronomers through definition of science cases. Developers will work on a certain task or project module for a few months before being moved to another area. In some cases more than one cycle or iteration is necessary to achieve a goal. In any case task assignment is under constant review by the project leaders, with a view towards reallocating human resources when and where they are needed.

The benefit of an approach like this is a highly cross-trained development team. For example in the case of a member's absence another developer who has previously worked on that area can be assigned the task. The fact that, at some point, they would have worked in the particular area will mean they can quickly re-integrate themselves into the development team for the particular project module. However, adequate facility for communication must be in place for developers to be able to exchange ideas and to make and to respond to queries, so that the development process is as efficient as possible. One important issue in relation to this cyclic development process is development by second parties. As well as communication facilities there are other ways to ensure that the collaboration is as effective as possible.

Standards play an important role in facilitating code development by second and third parties. Standard forms of software design and standard coding styles all play a part in reducing development time. Standard software design methods will aid in code integration and coding style standards will help reduce the time required for second party developers to familiarise themselves with software. Standard forms of code documentation can also greatly aid second party developers.

AstroGrid Development Process

Support for second party development in AstroGrid can be classified into three areas. Firstly, there are document repositories, news, notification, and a discussion forum to facilitate communication between members of the project. Secondly, there are the standards for the design and implementation of software generated by the project. Finally a considerable amount of documentation is required once the software is working. This documentation includes documents for the actual code, integration documents and testing documentation. Then a range of tools is used to tackle the problems posed by AstroGrid's needs for effective collaboration.

Communication

To facilitate good communication practice any person with expertise or simply an interest in the Virtual Observatory concept, Grid technologies or e-Science is free to post or comment upon news articles, participate in the forum exchanges or post documents making use of the AstroGrid portal. The portal provides an access point to the various communication tools available. The Wiki pages provide support for the posting of relevant documents for the project. Wiki is a leading-edge, web-based collaboration platform targeting the corporate Intranet world. TWiki [START_REF] Twikitm | Enterprise CollaborationPlatform[END_REF] fosters information flow within an organization. Some Wiki features are: web browser, auto links, text formatting, search, e-mail notification, structured content, attachment, templates and skins, statistics and plug-in resources. Further to the Wiki pages the AstroGrid portal provides a forum facility which provides a number of grouped discussion areas. The groups deal with site-related topics, project-specific topics and general areas such as virtual organisations and Grids. To allow developers to be kept up to date with various information about articles posted, items of news, events and polls, a news section is available. The idea of a central portal providing access to the various communication platforms is essential to effective collaboration. There is no confusion over how to contact other members as all contacts are made through the use of one central site. Further to these web-based community-oriented communication tools, one-to-one contact is necessary in order to ensure that developers can carry out their tasks efficiently. For example, in the case of second party development the ability to contact a previous developer to query some aspect of the work greatly reduces re-development time. To facilitate the necessary direct communications between project members, project contracted people keep close contact through e-mail, telephone conferences, chat programs and regular meetings.

Code

Integration Code is tackled using Current Version System [START_REF] Cvs | Concurrent Versions System[END_REF] to store, modify and keep track of code changes. This has various uses in software development practice helping returning developers to identify and understand changes that have been made since they last worked on a particular project area. JUnit [START_REF] Junit | JavaTM Testing Framework[END_REF] Test is used to prove code integrity and ensure quality of service. JUnit is a regression testing framework for code made with Java. Usually a unit test exercises some particular method in a particular context in order to prove that a specific piece of code does what it is supposed to do. Code bugs are tracked using Bugzilla [START_REF] Bugzilla | Bug-Tracking System[END_REF], a "Defect Tracking System" or "Bug-Tracking System". Defect Tracking Systems support individuals or groups of developers to keep track of outstanding bugs in their software effectively. Once an error, misbehaviour or unexpected answer has been detected, this will be described and assigned to a developer in the form of a ticket which contains all the information related with the bug.

In order to support re-use or re-development the following methods of providing reliable high quality software are important. When a piece of code is developed, in order for further work to be effectively carried out, it is essential that the product is of high quality. To provide standard coding practices a number of tools are used in the AstroGrid project. A range of free Integrated Development Environment (IDE) tools such as Eclipse [START_REF] Eclipse | Eclipse Foundation[END_REF] and JBuilder Foundation are used during the development process. These, in conjunction with code design standards (i.e. UML), are needed to establish the basis on which to allow different people in different places to modify each others' code easily, the philosophy being that if everybody is using the same tools to build a product the components of the product can be more easily modified or enhanced.

The main programming language used in AstroGrid is Java. Different standards like UML, XML and Web Services are used for the design process to maintain consistency. When implementing code in Java a coding standard is utilised, which allows different people to understand the work of each other, maintain coding style and consistency. This leads to a cleaner and easier coding process. AstroGrid code guideline standards are described in Vermeulen et al. [START_REF] Vermeulen | The Elements of JavaTMStyle[END_REF]

Documentation

Code management and documentation is addressed mainly through the use of standard Java code documentation and Maven [START_REF] Maven | Apache Maven Project[END_REF]. Maven is a Java project management and project comprehension tool. It is based on the concept of a project object model (POM) where all the Maven objects are a result of a well defined model. Builds, documentation, source metrics, and source cross-references are all controlled by the POM. Maven aims to make the developer's life easier by providing a well defined project structure, well defined development processes to follow and a coherent body of documentation that keeps developers aware of what is happening within the project. Maven alleviates a lot of what most developers consider drudgery and lets them get on with the task at hand. This is essential in projects where there are not many people dedicated to the task of documenting and spreading the critical information about the project, which is necessary in order to dedicate resources to other critical tasks as coding and coding testing.

Security

One problem not included in the above section is security and the identification of which information is publicly accessible and which is not. As AstroGrid is an open project, almost every document is publicly accessible through the Internet. One exception is the code, where there are restrictions in place as to who is authorized to upload and integrate code. In this case SSH [START_REF] Ssh | Secure Shell[END_REF] protocol is used to allow secure communication between developers and the server repository. Though remote login is the primary use of SSH, the protocol can be used as a general purpose cryptographic tunnel, capable of copying files, encrypting email connections, and triggering remote execution of programs. Currently AstroGrid uses SSH Version 2 which operates over TCP. In its simplest mode of operation, it connects to a server, negotiates a shared secret key, and then begins encrypting the session. A username and password are passed over the encrypted session and, if authenticated, the server starts a command shell over the encrypted session.

ASTROGRID AS ASTRONOMICAL GRID ARCHITECTURE

In concordance with the construction of the VO, AstroGrid has a modular architecture [START_REF] Linde | Astrogrid Architecture Thesis[END_REF], open to all contributions from either data, services or resources.

Figure 1 shows AstroGrid modular architecture at a high level which we explain in this section.

Portal: This is a server-based component which delivers an interface for accessing services in the VO. In AstroGrid all the components which need to interact with the users will do so through a Portlet. A portlet gives a modular and flexible layer. Any developer is able to add his/her own functionality by wrapping it on a portlet.

Community:

This allows the construction of flexible communities within a group. Then once the permission has been assigned to a community administrator, he/she will be responsible for assigning rights to individuals.

WorkFlow: This enables the construction of complex tasks like building queries and data analysis, upload/download data and render the output in a different format like tables or images.

Registry: This contains metadata descriptive information about resources available, which is based on IVOA standards. A resource can be a data set, web service, service, information on other registries, etc.

Common Execution Architecture: This concept also called by the initials CEA is an abstraction of application components and the necessary parameters to run it. Data Set Access: This is an interface component able to take a standard query, translate it into a dataset and execute it, and return later the result to the data centre. Astronomical Tool: A number of essential astronomical tools such as object catalogue builder SExtractor [START_REF] Sextractor | Object cataloguer for astronomical images[END_REF] and photometric redshift analyser HyperZ [START_REF] Hyperz | Photometric redshift[END_REF] (which are freely available) will be incorporated to AstroGrid through a portal wrapper.

MySpace: This defines a virtual space to allocate both temporal and long term data, such as data sets generated by queries submitted to databases. MySpace is not necessarily in a local repository, but it will interact with the user as easily if it were on a local machine.

Authorisation/Authentication: This is the component in charge of identification and granting of access to the users, as well as maintaining security in AstroGrid.

Grid Middleware: This allows AstroGrid to integrate different astronomical data centres and to share resources in a coordinated way.

Data Sets: Data allocated in a distributed way in different data centres across the United Kingdom in AstroGrid's case, and across the globe once the Virtual Observatory alliance will be fully working.

ASTROGRID AS E-LEARNING CASE SCENARIO

There is no single definition for the e-Learning concept just yet. We consider e-Learning as use of any electronic device to assist the education or training process, taking advantage of the Internet or any other communication channel to connect other devices to deliver information and knowledge.

The possibility of using the Virtual Observatory for e-Learning is at the moment limited and reduced to the research level. This is mainly due to the early stages of development and because a fully usable version has not been released yet.

When working, the Virtual Observatory is expected to provide a data-grid platform for astronomers and the scientific community. But it also can provide a good chance for students to experience grid computing in a real-case scenario.

This goes beyond the use of AstroGrid accounts to access information in the VO. Students will be able to implement experiments in areas such as image processing, algorithms and data mining in computer science related areas, just to name a few. But e-Learning does not stop there: it will The most interesting aspect would be the interaction of these individuals doing work as a group driven by common interest. Just as research projects such as AstroGrid work as a collaboration of individual researchers, students can reenact this by working in interdisciplinary groups, using the platform to learn to effectively share individual knowledge and expertise.

This scenario, however, needs adequate tools to coordinate, support and monitor such virtual groups. A starting point is to take Open Source software to generate an adequate bundle of software that will enable students to organise such a group.

e-Learning Service Architecture for the Virtual Observatory

The scenario presented above is not just a challenge for teachers and students: it also presents a challenge for the scientist working in today's Virtual Observatory.

Questions such as the following are on the agenda:

• What kind of service would we like to offer to e-Learners?

• What resources are the Virtual Observatories willing to allocate for non-heavy scientific analysis? • How are we going to present such information in a friendly, open way? • How will effectiveness and efficiency of VO e-Learning systems be evaluated? • Moreover how well prepared is our architecture of today to incorporate future e-Learning schemes?

Essentially all Virtual Observatories are based on open standards such as XML and Web Services. This makes the architecture transparent for incorporating customised plug-ins or extensions in the case of designing e-Learning modules.

The problem we find here, and must address, is that VO architectures can reach very complicated states, and the more complicated this is the more difficult to incorporate additional modules that can respond adequately to the learning process.

As our starting point we can consider Gilly Salmon's model for understanding learning via CMC [START_REF] Salmon | E-moderating: the Key to Teaching and Learning Online[END_REF] for implementing e-Learning modules that can be on the top of AstroGrid architecture. This model, shown in Figure 2, is derived from analysis of Computer Mediated Communication and it has become established as a course design tool. Salmon presents a five layer process leading to knowledge construction.

The advantage presented by this model is that it is rather close to the AstroGrid philosophy, since this approach is not formally but intrinsically related to the way that AstroGrid is developing today. Also it is a non-exclusive model, for example to ensure quality of services. Learning via the CMC model can interact with Allison's [START_REF] Allison | Quality of service requirement for the e-learning grid[END_REF] layers of distributed learning environments.

The Salmon model helps to understand the kind of service that we would like to offer to potential e-Learners. In a more concrete scenario we can consider the implementation of the Intelligent Web Teacher Platform (IWT) as described by Capuano et al [START_REF] Capuano | How to use grid technology for building the next generation learning environments[END_REF].

IWT is a distributed learning platform which offers external plug-in connectors that can be designed specifically to connect AstroGrid Portal. Since AstroGrid supports special designed portlets to access its resources, IWT presents a potential solution to facilitates the creation of an e-Learning environment for Astronomy.

CONCLUSIONS

This paper explores the current state of AstroGrid Virtual Observatory collaborative work, and the way in which the project is organized to reach its goals.

FIGURE 2 :

 2 FIGURE 2: Model for understanding learning via CMC

1st International Kaleidoscope Learning GRID on Distributed e-Learning Environments

We have discussed how this kind of grid-enabled project could be used as an e-Learning platform and environment, and we present two possible e-Learning models to be implemented in the Virtual Observatory.


N Capuano

M Gaeta
email: gaeta@crmpa.unisa.it

R Iannone
email: iannone@crmpa.unisa.it

F Orciuoli
email: orciuoli@momanet.it

st International Kaleidoscope Learning GRID on Distributed e-Learning Environments Workshop

Nowadays, the need for e-learning systems supporting a rich set of pedagogical requirements has been identified as an important issue in the field of distance learning. Several initiatives take place in order to meet this need. Maybe, the most important of these initiatives is IMS Learning Design [6] that provides a framework to depict pedagogies. Furthermore, we are aware that the provision of different learning paths tailored on learner's characteristics and preferences guarantees the learner to reach a cognitive excellence. In this paper, we first illustrate an extension for IMS Learning Design in order to overcome its limitations forcing instructional designers only describing domain-dependent pedagogies. Then, we propose a mechanism to build units of learning by merging domain-independent pedagogies with educational objectives selected by teachers inside a specific didactic domain modelled by a graph structure called ontology. Finally, we illustrate a delivery networked infrastructure able to execute units of learning in a personalized way based on learner preferences.

Introduction

Building individualized learning activities to support personalized instruction in an adaptive environment is a big challenge for the future of e-learning. The web offers the perfect technology and environment for individualized learning, since learners can be uniquely identified, content can be specifically personalized, and learners cognitive states progress can be monitored, supported and assessed [START_REF] Hummel | Koper -Educational modelling language and learning design: new opportunities for instructional reusability and personalised learning[END_REF]. An important result in e-learning field is achieved by IMS Learning Design (IMS-LD) that proposes a language for describing learning processes, called learning design scenarios, where users can play learning activities embodying several roles. Although IMS-LD is very useful for instructional designer to model, in a machine understandable representation, a wide range of pedagogies, nevertheless it does not support, in a native way, personalized formative paths since real contents and services are bound at design-time to the specific learning scenario that models the learning process. IMS-LD early binding thwarts the use of learner profiles that could be used as directives in order to build, at run-time, personalized learning experiences. Furthermore, nowadays several educational e-content repositories and networked infrastructures are available and accessible in order to delivery learning scenarios where services, users and contents are decentralized and selected at run-time in order to provide effective and reliable learning experiences all the time to final users. The main goal of this paper is depicting some ideas of extension for IMS-LD in order to model domain independent pedagogies as learning design scenarios. Domain-independent learning design scenarios will be used by teacher to construct domain specific units of learning by merging pedagogies with educational objectives extracted by ontologies used to model specific didactic domains. The units of learning will be bound with real contents and services at learners fruition-time in order to best fit their preferences and networked resources availability. The paper is structured as follows. In section 2 we present IMS-LD. The section 3 underlines some drawbacks of IMS-LD regarding its lack of support for domain-independence and personalized learning. In section 4 we propose our solution for IMS-LD drawbacks illustrating a scenario in which instructional designers and teachers/authors build units of learning (UoL) embedded in different domains based on a domain-independent learning design scenario. In the section 5 we propose a distributed infrastructure able to run learning experiences. The distributed infrastructure is presented by illustrating a scenario in which 1 st International Kaleidoscope Learning GRID on Distributed e-Learning Environments Workshop the units of learning constructed before are personalized and delivered to learners. Finally, the section 6 proposes some ideas for further works and conclusions for the paper.

IMS Learning Design (LD)

IMS Learning Design is a specification used to describe learning design scenarios. It allows these scenarios to be presented to learners on-line, and enables them to be shared among systems. It can describe a wide variety of pedagogical models, or approaches to learning, including group work and collaborative learning. It does not define individual pedagogical models; instead it provides a high level language, or meta-model, that can describe many different models. The language describes how people perform activities using resources (including contents and services), and how these three things are coordinated into a learning flow.

IMS Learning Design describes how a learning design scenario unfolds through the analogy of a theatrical play. Just as a play can be staged with different actors, in a different theatre with alternative props, so learning design scenarios can be executed again with different learners and tutors, on different systems, with alternative learning resources or tools:

 The play is presented in a series of acts, in which roles are played by those taking part, for example learner, tutor, mentor, and so on.

 People playing the roles undertake a series of activities within an act. For a learner these might include discussing with classmates the relative merit of a piece of source material. A tutor's activity may be to comment on their conclusions.

 Each role is presented with its own learning objects (LO) and services (e.g. communication tools) within an activity.

 An act is completed after all the activities of a specified role, or roles, are finished. Alternatively, a time limit may be set, after which an act completes.

 As soon as an act is completed, the next one starts. The play finishes when all the acts are completed, the learning design scenario finishes when all the plays are completed.

Services offer generic functions such as email, conferencing, searching and announcements. The locations of services are not specified during design, but are made available at run time, after people have been assigned to their roles. Both services and learning objects are referenced by activities. This means that these elements are located separately so that they can be reused and updated easily.

The model revolves around describing units of learning atomic or elemental units providing learning events for learners, satisfying one or more interrelated learning objective.

In a unit of learning, people act in different roles in the teaching-learning process. In these roles, they work towards certain outcomes by performing learning and/or support activities within an environment, consisting of learning objects and services to be used during the performance of the activities.

The approach separates learning objects and services from the educational method used in the unit of learning.

IMS Learning Design specifies a language for describing learning activities, and gives a binding for this language to XML (Extensible Markup Language).

An IMS Learning Design player (the execution engine) is a software tool that interprets, at run-time, the XML notation of a learning design scenario as participants work through it. The player may be a standalone tool, or it may be part of a virtual learning environment (VLE).

In conclusion IMS Learning Design orchestrates e-learning scenarios by:  Describing and implementing learning activities based on different pedagogies, including group work and collaborative learning.

 Coordinating multiple learners and multiple roles within a multi-learner model, or, alternatively, supporting single learner activities.

 Coordinating the use of learning contents with collaborative services.

 Supporting multiple delivery models, including mixed-mode learning.

1 st International Kaleidoscope Learning GRID on Distributed e-Learning Environments Workshop

IMS-LD and domain-independent pedagogies

The IMS Learning Design specifications are structured in three level. Level A includes activities, roles and environments. Activities (learning activities or support activities) can be grouped into activities structures and executed into specific environments. An environment is formed by learning objects and services provided to users during activity execution. Users are classified into roles (learners, teachers, tutors, etc…). Nowadays, learning objects are educational contents by which learners acquire knowledge and services are functionalities invoked during learning process in order to communicate with tutors or other learners. Level B adds properties (storing information about a single person or a group) and conditions (setting constraints upon the flow of activities) to the first level. Level C adds notifications (mechanism to handle messages passing between users) to the framework .

Focusing on Level A and B we observe that though IMS-LD presents a mechanism to personalize the learning experience at run-time using properties and conditions at Level B, however the instructional designer has to provide a fixed set of learning objects and services in which selecting contents and tools for learning experience final users. So we can consider that learning objects and services are statically bound to the learning design scenario.

Design-time resources binding (LOs and services) is affected by the following problems:

 Learning design scenarios implement domain-dependent pedagogies: the instructional designer is forced to establish "a priori" the didactic domain, building the environments tied to the scenario's activities.

 Learning processes cannot be really adaptive (based on learner profiles): systems for learning material delivery cannot take into account learner preferences and cannot select, at run-time, learning objects that best fit learners characteristics.

 E-learning scenarios don't exploit some advantages of distributed infrastructures: the early binding of resources at design-time thwarts the opportunity for dynamic selection of learning objects and services that best fits learning process needs. Of course, these needs can be better supplied if the source of resources is a whole virtual organization (on a networked infrastructure) than the environments linked to the learning design scenario.

Our proposed solution consists in modifying the learning design scenario authoring process specified by IMS-LD in order to provide only requirements for a desired LO rather than a reference to a real LO.

Requirements can be expressed using a subset of IMS Learning Resource Metadata (IMS-MD) [START_REF]IMS Learning Resource Meta-Data Information Model (Version 1.2.1 Final Specification[END_REF] specification. These requirements will be transformed in references to real LOs at learning design scenario execution-time. A learning design scenario with pending references to LOs can be considered a template learning design scenario [START_REF]Pythagoras Karampiperis and Demetrios Sampson -Designing Learning Services for Open Learning Systems Utilizing IMS Learning Design[END_REF]. In the next sections we propose a complete e-learning sample scenario in which an instructional designer describes a pedagogy using a template learning design scenario, an expert models a didactic domain, a teacher prepares a unit of learning based on the constructed template learning design scenario and the provided ontology. At last, a learner runs the unit of learning in a personalized way.

A complete e-learning scenario: building a Unit of Learning

unit of learning (UoL) is a sequence of learning objects (enriched by services provided to final users) assembled by a teacher to explain some concepts. In this section we show the overall process needed to build a unit of learning (based on a learning design scenario) that can be personalized at run-time with respect to learner preferences.

Pedagogy construction (first step).

First of all, the instructional designer builds a pedagogy using IMS-LD language though he doesn't specify real learning objects for each activity (through environments) in the play, on the contrary he/she assigns, for each LO in the learning design scenario, some requirements that learning objects should fulfil in place of setting references to real learning objects. The needed requirements are values for the following properties: learning resource type (LRT), interactivity level (IL) and interactivity type (IT) [START_REF]IMS Learning Resource Meta-Data Information Model (Version 1.2.1 Final Specification[END_REF]. IMS-LD, through the mechanism of environments, allows to specify more than one resource (LOs and services) within each activity but, without lack of generality, we will use only one resource for a single 1 st International Kaleidoscope Learning GRID on Distributed e-Learning Environments Workshop activity and one activity for each act. So, in our example, we will use the word "activity" in the place of the word "act". The constructed template learning design scenario (or LD document) is illustrated in figure 1. The previous LD document is based on an inductive method in which learners have to study a "not interactive" LO, a "narrative text" LO and finally they have to test the acquired knowledge interacting with an "exercise".

Didactic domain modeling (second step).

In this step, domain experts model didactic domains through ontologies definition [START_REF] Fensel | Ontologies: a Silver Bullet for Knowledge Management and Electronic Commerce[END_REF]. In our example we show the result of modeling process performed by an expert of "Calculus" domain. An example of ontology is shown in figure 2. Here we refer to the ontology-based approach illustrated in [START_REF] Capuano | Sangineto -An Integrated Architecture for Automatic Course Generation[END_REF].

Unit of Learning construction (third step).

Last step engages teacher that realizes the UoL overlapping domain-independent pedagogy and domain specific concepts that represent the learning objectives of the UoL.

Unit of learning -LRT = "Experiment" -IL = "very low" -IT = "Expositive" -t. concept = limit -LRT = "Narrative text" -IL = "very low" -IT = "Expositive" -t. concept = limit -LRT = "Exercise" -IL = "very high" -IT = "Active" -t. concept = limit Activity 2 Activity 1 Activity 3

Pedagogy applied to limit concept -LRT = "Experiment" -IL = "very low" -IT = "Expositive" -t. concept = derivative -LRT = "Narrative text" -IL = "very low" -IT = "Expositive" -t. concept = derivative -LRT = "Exercise" -IL = "very high" -IT = "Active" -t. concept = derivative In our example, teacher chooses the pedagogy (template learning design scenario) of figure 1, the ontology of figure 2 and the concept "derivative" as educational objective of his/her UoL. An automatic process uses inputs from teacher in order to: 1) Extract and organize in a sorted sequence all pre-requisites of the concepts "derivative", from selected ontology, obtaining the path [Limit, Derivative]; 2) Join the selected template learning design scenario with the sorted sequence resulting from the previous point; 3) Obtain the activities flow shown in figure 3 constructed applying the original pedagogy to each concept in the path [Limit, Derivative].

The activities flow is an enriched template learning design scenario with an additional requirement (concept) for each desired learning object. In the example of figure 3, the values for property called concept will specify that desired learning objects for activity 1, activity 2 and activity 3 have to explain the concept of "limit" in the domain of "Calculus". Instead, desired learning objects for activity 4, activity 5 and activity 6 have to explain the concept of "derivative" in the domain of "Calculus". So, the UoL is ready to be published and executed inside the infrastructure defined in section 5.

A complete e-learning scenario: a distributed delivery infrastructure

The distributed infrastructure that allows the delivery of the UoL, built in the previous section, is depicted in figure 4. It is based on three types of distributed services:  UoL Delivery Service, that allows the playing of the UoL for authorized users (enrolled to the learning experience as learners, tutors, etc…).  Localization Service, that allows to localize needed services. In particular, in our example, the Localization Service can be invoked in order to find available repositories storing correct (with respect to requirements in template learning design scenario) learning objects.  Repositories, that are services providing two main ports. The first port is invoked to query the learning objects archive in order to obtain a list of metadata representing LOs satisfying the query. The second port (delivery) is invoked to obtain the GUI (Graphical User Interface) that renders a specific learning object delivery. Delivery ports return frames of mark-up code (typically XHTML) that represent GUIs. These ports can be implemented as WSRP (Web Service for Remote Portlet) producers [1]. Search and Query LOs ports can be implemented as standard Web Services.

In figure 5 we present the detailed architecture of UoL Delivery Service that is composed by three tiers: 1) Services Connectors for remote services invocations; 2) Enhanced IMS-LD Engine [START_REF]IMS Learning Design Best Practice and Implementation Guide (Version 1.0 Final Specification)[END_REF] for learning flow resource binding and execution; 3) UoL Player for UoL rendering. An UoL delivery will walk across two phase: startup and run.

The first one is an initialization step where the UoL Delivery Service:  Retrieves the concepts, within the UoL, interpreting the enriched LD document that describes it.  Invokes (with respect to the didactic domain covered by UoL) the Localization Service in order to obtain the URL of one or more repositories providing learning objects. Localization Service maintains a registry (possibly UDDI) based on a primary level index that maps associations between didactic domains and repositories storing LOs related to these domains.  Performs queries over retrieved repositories with respect to concepts obtained by UoL. Queries return lists of metadata representing learning objects related to the required concepts.  Applies filters over lists, obtained in the previous step, using parameters associated to all activities in the UoL in order to obtain a single LO for each activity. If the applied filter returns more than one LO for the same activity the system can select a single LO using learner preferences (preferred media type) and the technical.format field [START_REF]IMS Learning Resource Meta-Data Information Model (Version 1.2.1 Final Specification[END_REF] of learning objects metadata.  Performs binding between activities and real LOs (resource identificator and repository URL) obtaining a personalized unit of learning.

The second one is the an execution step where for each activity the UoL Delivery Service:  Detects the resource identificator and the repository URL.  Gets WSRP mark-up code from the right repository delivery port using values obtained in the previous step.  Composes the obtained WSRP mark-up code with the overall GUI of UoL and returns the complete WSRP mark-up code to the client.

Conclusion and future works

In this paper we have presented a solution for the construction and execution of personalized learning experiences based on: 1) an extension of IMS Learning Design to meet the need for domain-independent pedagogies; 2) an ontology-based approach to model didactic domains in which we can plunge the domain-independent pedagogies to obtain units of learning ready to be personalized and executed; 3) a distributed infrastructure for personalized units of learning delivery.

As future works, we are planning to develop the presented delivery architecture extending the IWT (Intelligent Web Teacher) platform implemented by MoMA [START_REF]Intelligent Web Teacher[END_REF]. Furthermore, we are planning to enrich the IWT platform with a set of authoring tools to cover all phases of units of learning building process. Nowadays, we are making experience with some open source software like Coppercore [START_REF]Coppercore project: The IMS Learning Design Engine -Available from[END_REF] for learning design scenarios execution and Reload [10] for learning design scenarios authoring.

  Figure 1.

  Figure 2.

  Kaleidoscope Learning GRID on Distributed e-Learning Environments Workshop

Figure 3 .

 3 Figure 3.

  Figure 4.

Figure 5 .

 5 Figure 5.