A Step ahead in E-learning Standardization: Building Learning Systems from Reusable and Interoperable Software Components

A Step ahead in E-learning Standardization: Building Learning Systems from Reusable and Interoperable Software Components

Luis E. Anido-Rifón, Juan M. Santos-Gago, Judith S. Ródríguez-Estévez, Manuel Caeiro-Rodríguez, Manuel J. Fernández-Iglesias and Martín Llamas-Nistal
Universidade de Vigo
E.T.S.E. Telecomunicación
E-36200 Vigo, Spain
+34 986 814073
{lanido, jsgago, jestevez, mcaeiro, manolo, martin}@det.uvigo.es


This paper addresses the interoperability problem consequence of the proliferation of online learning systems, mainly in Internet environments, which is being considered by key standardization institutions and the most relevant educational software consumers worldwide. Up to this date, proposals are available for the standardization of information models, such as educational metadata or course structures.
Our main objective is to contribute to this standardization process with an original proposal for a service architecture to build standard-driven distributed and interoperable learning systems. This contribution is based on the definition of open software interfaces for each subsystem in the architecture, avoiding any dependency from specific information models.
To materialize our proposal, we have selected CORBA as the technological supporting infrastructure, defining a domain facility for e-learning. It provides the mechanisms whereby heterogeneous online learning systems are able to interoperate and exchange learning objects at runtime. Our architecture includes learning object repositories, packaging management, cataloguing and searching environments, learner administration and, of course, runtime environments for e-learning.


Standardization, Open Architectures, Interoperability, Learning Objects, CORBA


Advances in Information and Communication technologies, and specifically in Multimedia, Networking, and Software Engineering have promoted the apparition of a huge amount of learning resources. During the last years, thousands of electronic texts, images, movies, or Java applets have been developed for learning purposes in Internet environments.

To take advantage of this situation, new services were developed, and the search, classification, organization, and peer-to-peer exchange of learning resources by learners, instructors, and course developers are becoming commonplace. Metadata helps to carry out these tasks, and several specifications for learning objects were produced. Related to them, specialized search engines and indexing tools for learning were also made available.

However, to find the appropriate learning resource is not enough. The learning objects developed for a particular system may not be reusable in others. Formats for animations, videos, simulations, educational games, and multimedia are standards or well-known specifications, but to offer them to learners, these elements should be organized in a structured way, because they usually need to be processed by software tools prior to delivery. Additionally, information related to the interaction of learners with these contents should also be generated. Content structure formats maintain the static and dynamic structure of learning object aggregations. There are also specifications available for course packaging, to facilitate the transfer of courses among systems. In a similar way, it is necessary to manage information about learners, and their interaction with courses. All these elements have been considered by several international projects and most relevant standardization bodies. We have reviewed them, and a summary of this survey is included in section 2.

Also, the increasing use of the Internet and its technological capabilities, in addition to the huge amount of learning resources, allowed a high number of technology-based learning platforms to show up. As they are usually developed ad-hoc, to meet the requirements of a particular institution, heterogeneous systems appear with no interoperability mechanism among them. When these systems are reviewed, our conclusion is that they provide very similar functionalities: content delivery, learner tracking, learner management and administration, questionnaires evaluation, communication and collaboration facilities, search tools, etc. Therefore, we can state that most online learning systems share some common functionality, usually implemented from the scratch by each one of them. In this sense, software reuse would be a must to reduce the time-to-market factor.

On the other side, there is a lack of interoperability mechanisms among heterogeneous platforms. Such mechanisms would allow, for instance, that a particular online learning system would provide its own content delivery module, which uses a common learner administration system provided by an external institution and, maybe, developed by a different vendor.

The identification of a common architecture, composed of basic software components that provide open interfaces, would contribute to both reuse and interoperability. Standardization would be reflected here through the definition of agreed interfaces for these components.

Our work is mainly focused on this area. The second part of this paper, section 3, is devoted to the presentation of CORBAlearn, a proposal for a service architecture supporting the development of distributed, interoperable and standards-driven e-learning systems. As final products, within these learning applications we can distinguish two clearly separate aspects. On the one hand, we can identify the common services provided by CORBAlearn. On the other, we can recognize specific elements that the final application programmer must implement to provide the user interface and the particular functionalities (i.e. value-added services) of each concrete learning application. Section 4 discusses some examples of final applications that can be developed using the services provided by CORBAlearn. We will finish this paper with some conclusions in section 5.


The e-learning standardization process is an active, continuously evolving process that will last for years to come, until a clear, precise, and generally accepted set of standards for educational-related systems is developed. Among the main contributors to this effort let us mention the IEEE's Learning Technology Standardization Committee (LTSC) [1], the IMS Global Learning Consortium [2], the Aviation Industry CBT Committee (AICC) [3], the US Department of Defense's Advanced Distributed Learning (ADL) initiative [4], and projects Alliance of Remote Instructional Authoring and Distribution Networks for Europe (ARIADNE) [5], Getting Educational Systems Talking Across Leading Edge Technologies (GESTALT) [6], PROmoting Multimedia access to Education and Training in EUropean Society (PROMETEUS) [7], European Committee for Standardization, Information Society Standardization System, Learning Technologies Workshop (CEN/ISSS/LT) [8], Gateway to Educational Materials (GEM) [9], and Education Network Australia (EdNA) [10]. The IEEE's LTSC is the institution that is actually gathering recommendations and proposals from other learning standardization institutions and projects (c.f. Figure 1). Specifications that have been approved by the IEEE go through a more rigorous process to become ANSI or ISO standards. In fact, an ISO/IEC JTC1 Standards Committee for Learning Technologies, SC36 [11], was approved in November 1999.


Figure 1: Main contributors to the e-learning standardization process


The outcomes of these standardization efforts can be identified into two levels:

  1. Specification of the information models involved. Several proposals have been produced to specify the format, syntax and semantics of data to be transferred among heterogeneous platforms (e.g. courses, learner profiles, evaluation objects, etc.).
  2. Specifications of the architectures, software components and provided interfaces. So far, results have been scarce. In any case, some proposals have been already identified for the software components responsible for managing the information models in the first level of standardization.

Many Internet programmers develop their applications following a three-tier architectural style [12]. Persistent data is stored in the first level of this architecture, the back-end tier. The second level is the business logic tier. This one is responsible for managing data according to the expected functionality. Finally, the front-end or presentation tier supports the user interface. In terms of this architectural style, the first level of standardization presented above would provide standards for the back-end tier, while the second level of standardization deals with the business logic tier (c.f. Figure 2). There are also some recommendations for the presentation tier (e.g. user interface recommended icons by AICC [13]) although results here are less relevant. Main results from the first level are summarized in section 2.1. Outcomes from the second level are discussed in section 2.2. Section 2.3 discusses these works from the perspective of our proposal.


Figure 2: Three tiered architecture and standardization levels


2.1 First Level of Standardization. Data and Information Models

The more mature results correspond to this first level. In most cases, XML [14] is used to define supporting information models enabling interoperability in WWW settings. Standards at this level can be seen as common specifications that must be used by different vendors to produce learning objects. Figure 3 illustrates this concept using an example from the car manufacturing environment. In that setting, common specifications define standards to make, for example, tires for car wheels. As shown in the figure, the standard allows different vendors to produce tires that can be used by different cars. In the same way, common specifications for learning objects would allow their use by different educational software tools.


Figure 3: Standardization in car manufacturing. Interoperability at the back end tier


Relevant specifications at this level address:

  • Metadata: information used to define, as precisely as possible, educational contents. The most outstanding contribution so far is the Learning Object Metadata (LOM) specification [15] proposed by the IEEE LTSC, which is becoming a de-facto standard. This is one of the most active standardization areas, and several proposals are available. We have identified the relationships between the LOM specification and other works available [16].
  • Learner profiles and records: information that characterize learners, their knowledge and preferences. The IEEE LTSC Public and Private Information (PAPI) specification [17] describes implementation independent learner records. Another important specifications are the IMS Learner Information Packaging Specification [18], and the IMS Enterprise Data Model [19], aimed at e-learning administration, including group and enrolment management.
  • Educational content organization: data models to describe static and dynamic course structure. Static course structure defines the a priori relations among course contents (lessons, sections, exercises, etc.), whereas course dynamics determines the particular vision that users have depending on their attributes and previous interactions. This information is used by learning environments to understand the course structure and schedule next student activities. The AICC guidelines for interoperability of Computer-Managed Instruction (CMI) systems [20], and ADL's SCORM [21], based on the AICC specification, deal with this problem.
  • Other standards address content packaging to facilitate course transfer among institutions (IMS Content Packaging Specification [22]), question and test interoperability (IMS QTI specification [23]), learner tracking, competency definitions, and many others that are still in their early definition stages.

A comprehensive survey on the e-learning standardization process can be found in [24].

2.2 Second Level of Standardization. Common Software Components and Open Architectures

At this level, standards define the expected behavior of software components responsible for managing learning objects in online environments. Revisiting the car manufacturing example above, second level standards would specify the interface for the robots that assemble tires in a production line. These specifications let different manufacturers to produce robots with the same behavior (c.f. Figure 4). Performance may vary but the expected behavior as defined by the specification (top of the figure) must be implemented by different manufacturers' robots (bottom of the figure). Therefore, a production line could be composed of robots developed by different manufacturers provided they are compliant with the defined specification to support interoperability. In the same way, software interfaces for educational components would allow us to build new online learning systems avoiding their development from scratch, and also to provide interoperability among heterogeneous systems at runtime.


Figure 4: Standardization in car manufacturing. Interoperability at the business logic tier


Up to this date, only some institutions have developed architectures that contain common components for a generic learning environment. With respect to management and administration, we can identify three major categories of systems:

  • Educational Delivery systems: software products or suites that facilitate the delivery of contents, or support web access, which are not necessarily intended to measure performance or handle administrative tasks. Placeware Auditorium [25] and Centra's Conference [26] are examples of an Educational Delivery System.
  • Computer-managed Instruction (CMI) systems: software products that incorporate educational delivery for courses, and provide integrated tools for measuring outcomes and reporting progress for individual or groups of students. Examples include Blackboard's product [27] and WebCT [28].
  • Learning Management systems (LMS): software products that provide learners with an integrated view of all their active coursework and assignments in a "syllabus" that spans multiple courses. Examples include Docent Enterprise [29], ISOPIA [30] and Knowledgesoft Enterprise [31]. The LMS term refers to the whole learning scenario, including collaboration, resource location, etc.

At this level of standardization, proposals to define such systems range from the specification of conceptual models to concrete interfaces for CMIs. The IEEE LTSC's Architecture and Reference Model working group delivered in November 2001 the 9th draft of the Learning Technology Systems Architecture (LTSA) [32]. The LTSA specification corresponds to a conceptual model applicable to a broad range of learning scenarios. It is pedagogically, content, culturally and platform neutral. Although five refinement layers are specified (c.f. Figure 5) only layer 3 is mandatory. This layer identifies the architecture components, comprising four processes, Deliverer (D), Learning Entity (LE), Evaluation (E) and Coach (C); and two stores, Learning Resources (LR) and Learner Records (R).


Figure 5: LTSA architecture


There are two main proposals for concrete software architectures and components in a distributed e-learning system. The more elaborated one comes from the GESTALT project [33], which identifies a system architecture for online learning platforms based on a functional architecture and a reference business model. The GESTALT proposal is based on and integrates components from previous ACTS projects [34] GAIA, Renaissance and Prospect. The system architecture comprises a learning environment, an administration system, an asset management system, a service for user profiles, and a resource discovery service. Business objects comprising the interfaces among the various software components within the GESTALT architecture are also identified.

In the US, the IMS project started in 1997 defining a system model and architecture for learning environments. They abandoned this work very soon, as they considered of prior interest the development of data and information models to be managed by such architectures. In fact, although its work in architectures has not been resumed at the time of writing this paper, the IMS project has been a very active member at the first level of the e-learning standardization process (c.f. section 2.1).

A critical component inside a learning system is the runtime environment, responsible for delivering learning objects to students and tracking their progress. In the past, authoring systems made the customer a captive of his own delivery system. Many times, it was very difficult or even impossible to transfer learning objects created for a particular delivery platform to another one. To avoid this dependency, there should be provided a common way to initiate contents and to communicate them to the delivery and management system through a standardized data model. The US Department of Defense's ADL initiative has defined a Runtime Environment [21] directly based on the "AICC CMI Guidelines for Interoperability" specification [20] as part of its SCORM model. The ADL Run Time Environment includes a specific launch protocol to initiate learning objects, an Application Programming Interface (API), and a data model defining the communication at run-time between a learning object and its management software component.

2.3 The Second Level Revisited. A Critical Analysis

The projects introduced above are directly related to the work proposed as the main contribution of this paper. However, they do not cover the stated objectives at the second level of the e-learning standardization:

  • IEEE's LTSA architecture is a conceptual model. Therefore, it does not to provide specific interfaces used by real educational software systems.
  • Project IMS discontinued its work in architectures before publishing relevant results.
  • Project GESTALT identified the system architecture depicted in Figure 6. As the components of their functional architecture (boxes in the figure) are the result of previous ACTS projects, they do explicitly state that internal interfaces are not among the objectives of their work. Nevertheless, these internal interfaces are extremely important from a software reuse point of view because they are needed to build new systems in a scalable way. In addition, after the project deadline they only published part of the external interfaces (those marked as "interfaces published" in the figure). However, published documentation [33] does not completely define the behavior that must be provided by the components compliant with the specification. Besides, in our opinion interfaces are underspecified and not adequately documented.
  • Available specifications for runtime environments are clearly defined, and the works by AICC and DoD's ADL have already proven their value in practice. However, in this case we are restricting the interface definition to a very specific element of a complete e-learning environment (marked with a thick arrow in the figure). The aim of our proposal is to cover all relevant aspects in a distributed e-learning system.


Figure 6: Software interfaces as defined by the GESTALT project



From the previous section we can conclude that the first level of standardization has already produced mature specifications, and some proposals are considered de-facto standards (e.g. LOM metadata specification). However, results at the second level have been scarce so far. There is still a lot of work to be done to provide suitable standards for the business logic tier.

Our purpose is to contribute to this second level of standardization by the identification of common services for e-learning that will be supported by a Reference Architecture. This architecture will be composed of reusable software components with open and clearly identified interfaces. All interfaces in the architecture define their externally visible properties to facilitate the development of distributed, interoperable, and standards-driven online learning environments.

As a part of our contribution, we propose a concrete instance of the Reference Architecture for a particular implementation. The selected technology is CORBA [35], an object-based distributed architecture that allows distributed and heterogeneous applications to interoperate on a network. CORBA is a standard defined by more than 800 institutions that form the Object Management Group (OMG) [36]. Over a software bus, the Object Request Broker (ORB), CORBA objects interact with each other via standard contracts written in the Interface Definition Language (IDL). The OMG has also defined the interfaces for 17 basic services for distributed computing [37]. Nowadays, one of the key activities is the definition of higher level services, clearly oriented to a particular business domain: domain CORBA facilities. Already available domain facilities [38] are targeted to domains like Telecommunications, Manufacturing, Finance or Healthcare (c.f. Figure 7). They identify the objects needed, and their interfaces, in those domains to cover the needs of a wide range of requirements. Different vendors may change the implementation, but the offered functionality is basically the same thanks to the agreed interfaces.

Thus, CORBA domain facilities contribute to the interoperability among systems. At the time of this writing there is no domain facility for e-learning. In addition, the OMG is an open consortium with no ties to particular software platforms or programming languages. Eventually, CORBA objects can communicate through Internet using the IIOP protocol. For all these reasons, we chose CORBA as our middleware framework among other available options (e.g. DCOM or Java RMI). Our Reference Architecture will be put into practice through the proposal of a new domain CORBA facility for e-learning: CORBAlearn.


Figure 7: OMG Management Architecture (OMA)


3.1 Development Methodology: Obtaining Common Services to Build E-learning Systems.

Services supported by the Reference Architecture and eventually provided by CORBAlearn are the consequence of the application of an appropriate design methodology. This methodology, which can be seen as a side contribution of this paper, is devoted to the definition of service architectures starting from user requirements. It is based on the Unified Software Development Process [39] together with the recommendations by other authors [12]. The Unified Process' aim is to obtain a final product. On the other side, our aim is to define a service architecture to build final applications upon it. For this, we adapted the Unified Process to serve our needs. We included a Reference Model as an initial stage and defined a Reference Architecture as an intermediate stage. The overall process is illustrated in Figures 8 and 9. Modeling was made using the Unified Modeling Language (UML) [40] and its profile for CORBA [41].

The Unified Software Development Process is an iterative and incremental process, based on the architecture and driven by use cases. Basically, its foundation is an identification of the functionalities that must be provided to the users. Then, analysis and design models are developed to provide the functionality required.


Figure 8: Development methodology I


First, we identified a business model for the e-learning domain. This model corresponds to the Reference Model presented by Bass [12] and describes the key agents participating in the e-learning process (section 3.2) identifying the data flows among them (step 1). The Reference Model is derived from an analysis of the e-learning domain [42][43], a survey of the main proposals made by the institutions involved in the e-learning standardization process [24], and previous authors' experiences [44][45][46][47].

Once we have obtained a Reference Model, we proceed to functional requirements capture using artifacts from the Unified Process (step 2). This task is performed from use cases, considering the most common functional aspects in e-learning systems. Note that the eventually defined software services should be as general as possible, and therefore suitable for most learning tools. From the domain analysis, we concluded that different e-learning systems define different sets of actors, although some actors appear in practically all relevant systems (e.g. learner, tutor). Additionally, some contributions to the e-learning standardization process address the identification of relevant actors and their responsibilities within e-learning systems. After a thorough analysis, we decided to use for functional requirements capture the actors defined by the ERILE [48] specification. In other words, for each of the elements in the Reference Model we extracted the relevant requirements assuming the actors in ERILE were the target users.

The Use Case Model reflects requirements capture from the actors' perspective. Along a next analysis phase (step 3) we will study and further investigate these requirements from the perspective of the designers and developers responsible for building compliant systems. This lets us further understand system requirements as a first step towards a stable architecture. Responsibilities are assigned to analysis objects to assure that all user requirements are fulfilled by collaborations among analysis objects. The analysis model will serve as the basis to define a Reference Architecture [12]. For this, those analysis classes that have been assigned fundamental responsibilities to build final systems or to encapsulate information models from the first level of standardization are assigned to service packages.

Service packages are the foundation of a Reference Architecture for standards-driven e-learning systems (step 4). The Reference Architecture is a decomposition of the Reference Model into a set of components that provide the functionality identified along previous stages (steps 2 and 3). Note that, in a general sense, our objective is the definition of a set of services to facilitate and speed up the development of standardized, distributed and interoperable e-learning systems. Thus, we will only include in the service packages determining our architecture those analysis classes offering basic, common services. Additionally, the selected classes should be reusable and independent from specific learning domains or specific value-added services. Specific subsystems in the architecture should be implemented in an integral manner. In fact, these subsystems model class groupings that typically evolve together. Those analysis classes that are too application-dependent or represent value-added services will be assigned to the wrapper. Final applications demanded and used by the actors in the use case model will be composed by the defined service packages and analysis classes external to them. As in other standardized fields, external components (i.e. external analysis classes) will provide specific features and value-added services that characterize individual, may be competing learning systems. In other words, this external wrapping will provide a differentiation among proposals from distinct developers and institutions.

As the Reference Architecture includes only classes from the analysis model, it is implementation independent and purely conceptual. In the design stage (step 5, see Figure 9) we state our implementation environment. Here, each design artifact was elaborated taking in mind that CORBA was our selected implementation technology. Models at this step use the UML profile for CORBA. Also, as our final objective is to propose a domain facility, we focused on the design and definition of those interfaces provided by the design subsystems. Interface definition was made using IDL, and was thoroughly documented, as it is the core for any business logic-centered specification (c.f. Figure 2 and 4).

Thus, this proposal is materialized as a CORBA domain facility for e-learning: CORBAlearn (step 6). CORBAlearn is a specification, as it is the LOM specification for metadata; where CORBA was chosen as the implementation/deployment environment, as XML provides a concrete representation for LOM. Services offered by CORBAlearn are used by developers of final e-learning platforms, who would add a wrapper that makes use of them and adds application-specific value-added services to differentiate systems from different vendors (see bottom of Figure 9). Also, the core provided by CORBAlearn, whose specifications would be published in the framework offered by the OMG and its domain facilities, would support interoperability among heterogeneous platforms.


Figure 9: Development methodology II


3.2 Reference Model

As discussed above, the Reference Model is obtained from an analysis of the domain and previous authors' experiences. We have identified three elements in a Reference Model for e-learning (c.f. Figure 10). Educational Content Providers (ECPs) are responsible for developing learning objects. They are equivalent to publishers in conventional education. Educational Service Providers (ESPs) are the schools, universities, or academic institutions in these virtual environments. They are responsible for offering high-quality online learning environments. ESPs use ECPs to access, maybe under payment, online courses to be offered at their institutions. This could be done directly or indirectly, using a Broker, which is the third party involved. Brokers are responsible for helping both learners and ESPs to find suitable learning resources: learners will use Broker services to find and locate those institutions (ESPs) that offer courses they are interested in; ESPs will use Broker services to find learning resources offered by the ECPs to enrich their catalogues. To offer these services, Brokers must maintain metadata information about courses offered by associated ESPs and ECPs.


Figure 10: Reference Model


3.3 Reference Architecture

The Reference Architecture is a decomposition of the Reference Model, reflecting all components implementing the functionality identified in steps 2 and 3 of the proposed methodology (c.f. section 3.1), together with the corresponding data flows. Basic functional requirements are fulfilled by the Reference Architecture, whereas others, qualified as "value-added services", are assigned to the wrapper (c.f. Figure 8). The Reference Architecture is obtained from a detailed analysis of the functional requirements, and includes further specific requirements identified along this analysis process. Elements in the Reference Architecture are identified from loosely coupled service analysis class packages, which in turn are composed by tightly coupled objects. The proposed Reference Architecture [12] is a service architecture enabling component reuse. This is the main reason to adopt as the building blocks of the Reference Architecture the service packages identified along the process described in section 3.1. A further insight into the methodological approach to obtain this architecture can be found in [49].

Figure 11 outlines the proposed Reference Architecture, including the Reference Model decomposition into Reference Architecture elements and the analysis package each service package belongs to. We will briefly introduce its aims along the next paragraphs.


Figure 11: Reference Architecture


3.3.1 ESP reference architecture elements

We identified six subsystems for the ESP Reference Architecture:

  • Learners Administration. It offers services to develop management systems for administrative information concerning Learners, the actor in ERILE representing students or trainees. Actual implementations should offer introspection mechanisms to identify supported profile data models. This subsystem also provides the business logic for Learner registration and enrollment.
  • Employee Administration. This subsystem deals with administrative data for the rest of the ERILE actors that interact with the ESP: Tutors, Teachers and Reviewers. No standard specifications are available at this time to define the underlying data formats. However, models from other domains can be used (e.g. vCard [50]), or specific categories from the Learners specification.
  • Course Repository. It supports the development of repositories at ESPs responsible for course management and storage. Specifications for course structures are used in this subsystem to facilitate its use by Runtime Environments (see below).
  • Catalogue Management. Developers of ESPs would use this subsystem to build cataloguing and searching tools. Metadata specifications are used to handle descriptions of the learning objects delivered by the ESP. It includes customizable searching services using Learner's profiles to adapt searches to particular learning/presentation preferences.
  • Unpackaging Management. Services offered by this subsystem allow the unpacking of courses transferred from ECPs using encapsulated units (packages), compliant to a given packaging specification (e.g. IMS packaging [22]).
  • Runtime Environment. This subsystem is responsible for supporting the development of new delivery/runtime environments. Services offered include scheduling of learning object delivery (using both the static and dynamic views of a course structure, etc.), Learner tracking, or adaptation of contents to student preferences. It is directly based on the LTSA proposal, where both processes and persistent storage have been included [49].
3.3.2 ECP reference architecture elements

In our model, ECPs are built from three different subsystems:

  • Course Repository. It handles the creation, storage and management of learning objects. In comparison with ESP's Course Repository, ECPs includes facilities to support the development of new learning objects, including fine-grain management. Available course structure format specifications have been considered.
  • Catalogue Management. This subsystem offers services to support the development of catalogues for the learning objects provided by the ECP, including searching services, both external (to locate courses to be transferred to ESPs) and internal (to locate those learning objects that can be reused to build new contents). Metadata specifications are used to describe the learning objects available at the ECP.
  • Packaging Management. Developers of ECPs use this subsystem to create applications to transfer all the resources related to a course (learning objects, course structure, and metadata descriptions) among heterogeneous platforms in encapsulated units ensuring there is no loss of information. As for its counterpart in the ESP, specifications for content packaging are used to create packages.
3.3.3 Broker reference architecture elements

Brokers that intermediate between ECPs and ESPs or between ESPs and Learners are developed from basic services offered by four subsystems:

  • Broker Core. This is the fundamental subsystem that provides basic services to implement searching, publication and retrieval of educational resources. Services correspond to basic features needed to handle broker catalogues, which include both resource descriptions and descriptions of the services offered on these resources by providers. Metadata specifications are also handled by this element.
  • Profile Management. Using the services offered by this element, the wrapper is able to customize searches and notifications to the particular characteristics of each user. Profile data models and metadata specifications were considered here, including support for translations from profile records to metadata specifications. For this, we used mappings like the ones suggested by the GESTALT project [51].
  • Notification Management. An asynchronous notification facility can be build over the services provided by this subsystem. Subscribers to the notification service would be reported whenever a new learning object that fits their requirements is published through the Broker.
  • Federation Management. Brokerage capabilities will be clearly improved if intermediation is performed by the collaboration of a group of Brokers. The Federation Management subsystem supports the management of federation topologies and the use of federated searchers whose results may come from different sources (i.e. federated Brokers). Apart from metadata describing learning objects, this element also deals with the use of Quality of Service (QoS) recommendations.
3.3.4 Basic Properties of the Architecture

The basic properties of this Reference Architecture are:

  • Service architecture based on reusable subsystems. Architecture subsystems correspond to reusable service packages embedding fundamental services horizontal to the e-learning domain. The only additional elements for basic e-learning systems are boundary classes representing user interfaces and logic control for other subsystems in the architecture.
  • Standard-driven architecture. Subsystems in the architecture correspond to components implementing business logic and information models identified by standardization bodies and institutions. However, no dependency to specific proposals has been established. Actual bindings to existing information models are left for the implementation stages. Implementation should then offer introspection mechanisms to find out the supported models. Most modifications and updates will affect single components. Dependencies in the existing information models and user requirements have been thoroughly analyzed prior to component decomposition.
  • Scalability. Construction of final systems can be done as an incremental process through the successive assembling of new elements from the architecture. Architecture subsystems are loosely coupled, and dependencies are directed from more complex to more basic components.
  • Adaptability. The clear identification of each subsystem's role through use case realizations [49], decomposition and dependency analysis supports the replacement of specific subsystems by functionally equivalent ones.
  • Oriented to local changes. Different functional requirements or standardized information models are handled by different subsystems in the architecture. Therefore, changes in both requirements and formats for the information models involved would require the modification of few, and usually one, subsystem.
  • Interoperability among heterogeneous systems. Open software interfaces and a common Reference Architecture will support interoperation, provided final systems conform to the architecture. Added-value features are then implemented through the elaboration of wrapper classes.

3.4 CORBAlearn: Design Model and Specifications

The elements defined in the design model are the design counterparts of the more conceptual elements defined in the analysis model, in the sense that the former are adapted to the implementation environment, whereas the latter (analysis) elements are not. In other words, the design model is implementation-oriented in nature, whereas the analysis model is more conceptual. From the Reference Architecture elements we derive a set of design service subsystems (c.f. Figure 12). Reference Architecture subsystems have been assigned with specific responsibilities. Along design, service subsystems will materialize these responsibilities in a concrete programming language or, as in our case, interface definition language. At this stage, we selected CORBA and the framework provided by the CORBA domain facilities as the implementation environment. Each service subsystem is defined using a separate specification where service interfaces, data structures and exceptions are included. There is also a set of common specifications, horizontal to the whole domain facility. Together, they form our proposal for a new CORBA domain facility for e-learning: CORBAlearn. The whole set of specifications (for the three elements in the Reference Model) includes 69 service interfaces and a total of 888 method definitions. Let us recall here that, as our aim is to propose a domain facility, we focused on interface definition. Products from different vendors may provide different performances, but their functionality must be the same if they claim to be compliant with the interface.


Figure 12: From a Reference Architecture to a specific Design Model


CORBAlearn covers all aspects in a distributed e-learning system identified by the Reference Architecture. Each of them is supported by a different specification of the CORBAlearn domain facility. For the sake of brevity, we just present here part of the static and dynamic view of the software architecture and its object IDL interfaces. We encourage the reader to request the whole set of specifications [52] to the authors.

3.4.1 Common Specifications. An example

Common specifications include the definition of data structures and service interfaces useful in several subsystems. Among others, we have specified a set of generic IDL structures (c.f. Figure 13) to encapsulate information models following a tree-like structure (e.g. like XML or DOM documents). Therefore, we provide a straightforward mechanism to use those proposals from the first level of standardization, as most of them use XML as the data definition format. On the other side, there are no bindings to particular proposals for information models. These structures are generic enough to encapsulate different alternatives.


Figure 13: Category, Element and Attribute specification to encapsulate tree-like information models


3.4.2 ESP specifications. An example

Figure 14 shows some of the interfaces included in the CORBAlearn Runtime Environment subsystem. Note that the figure only presents method definitions but not the parameters for each of them. The purpose of these interfaces is to support interoperability for runtime environments. As a result, developers of final e-learning systems are freed from common design tasks, like learning object delivery, student tracking or evaluation. Service interfaces presented in the figure are:

  • NavigationManager. This interface is responsible for scheduling the next element to be delivered to students. It also provides navigation through the course structure, taking into account previous learners' actions and fulfilled prerequisites. Objects implementing this interface are equivalent to the process Tutor of the IEEE's LTSA (see section 3.2).
  • Presentation Manager. Its main responsibility is the customization of learning objects delivered to learners according to their personal preferences, maintained in their profiles or explicitly defined for each course. Objects implementing these interfaces are partly equivalent to the process Delivery of the IEEE's LTSA.
  • CoursePreferencesRepository. It provides services for accessing and managing preferences for each particular course. Preferences and presentation patterns may be grouped and applied together.
  • SCOInteractionManager. This interface is responsible for tracking and trace storage, and management at each Sharable Content Object. Information models here correspond to the DoD's ADL SCORM runtime data model.
  • SCOEvaluator. Its main responsibility is to decide whether or not the student has successfully completed and passed a learning object.
  • CourseEvaluator is responsible for evaluating the course as a whole, and for updating the learner's profile transcript accordingly. Objects implementing the last three interfaces are equivalent to the process Evaluation in the LTSA model.

Other available service interfaces in this subsystem deal with storage and management of runtime data models, and support the development of supervision and tracking tools for tutors and teachers responsible for monitoring students.


Figure 14: Some interfaces of the CORBAlearn Runtime Environment


3.4.3 ECP specifications. An example

For this paper, we have selected the CourseRepository subsystem interfaces as the representative for the ECP specifications. The overall purpose of these interfaces is to facilitate the development, management and storage of learning objects in different aggregation levels: assets, learning objects as its most basic form (text, images, Java applets, sound files, etc.); SCOs, a set of assets that forms the smallest indivisible learning object that can be delivered to a student (e.g. an Web page containing an HTML file, several images, sound files and movies); and courses as the structured collection of SCOs with an associated dynamic behavior (course structure). We have defined five service interfaces (c.f. Figure 15):

  • Asset Manager, which offers methods to upload, manage and describe each individual asset.
  • SCOManager, which offers methods to manage SCOs, to bind assets to them, and to define the main asset or entry point to an SCO (in a Web page the main asset would be the HTML file), etc.
  • CourseManager, which manages groups of SCOs (blocks), their properties, and the binding and unbinding of SCOs. It is the interface where course structures are defined, including their dynamic behavior (prerequisites).
  • CoursePreviewManager. It allows the development of previews for a course in the form of a static SCO.
  • CoursePreviewSupplier. It handles the delivery of existing previews to a potential requester.

>From the services provided by products compliant with these interfaces, less effort would be required to develop a final Web-based authoring tool. Most of the work would be to develop an appropriate user interface (which would belong to the wrapper), as management and learning object organization is dealt by the CORBAlearn facility.


Figure 15: CORBAlearn ECP Course Repository interfaces


3.4.4 Broker specifications. An example

As example for the Broker, Figure 16 shows the interfaces that describe the CORBAlearn Notification Management specification. The main interfaces are Notification Manager and Notification Finder. Both of them provide introspection methods to discover the formats for resource description (i.e. metadata), and service descriptions supported by the implementation of each one of them.

  • The Notification Manager interface provides methods to subscribe users, to manage their profiles, and to identify, through metadata-based triggers, what kind of learning objects the subscriber should be reported about, and the notification method that should be used.
  • The Notification Finder is responsible for identifying those subscribers that should be reported about a particular update on the Broker's catalogue. This search is based on the learning object metadata description and services offered by its provider. Access to results is managed through the services included in the Notification Iterator interface.


Figure 16: CORBAlearn Notification Service interfaces



Along the previous section we discussed the development of the CORBAlearn domain facility. Specifications provided as IDL interfaces contribute to the e-learning standardization at the business logic tier. Different vendors claiming compliance with this specification would offer products that provide the services defined in these interfaces. Over these basic services, developers of final applications build the wrapper, (c.f. Figure 9) where user interfaces are embedded and additional value-added services may be included.

There is no restriction in terms of wrapper technology. The only assumption is that it is able to use CORBAlearn services through a CORBA software bus, which may be accessed from most WWW browsers. Also, the wrapper may be distributed among the server and client, or may be totally embedded in the client. Figure 17 shows two different scenarios for a final system implemented in a WWW setting using CORBAlearn facilities.

On the right side of the figure, we assume that the wrapper is distributed between server and client. The client side of the wrapper provides the presentation tier (i.e. user interfaces) from where commands are sent to the server side of the wrapper. The latter uses CORBAlearn facilities to implement basic commands and, probably, it also may encapsulate some other additional features.

On the left side of the figure, the whole wrapper is downloaded to the client, both the presentation tier and the business logic implemented by the wrapper. HTTP is used for downloading, while Internet Inter ORB Protocol (IIOP) is used to access CORBA objects for subsequent accesses to CORBAlearn services.

Figure 17: Different solutions for final architectures

At the time of this writing, the whole set of CORBAlearn specifications have been implemented and tested from a Web-based wrapper following the approach shown in the right side of Figure 17. As an example of the CORBAlearn usability, we briefly describe along the next paragraphs how a product compliant with the RuntimeEnvironment specification can provide (CORBAlearn-compliant) WWW-based content delivery and tracking tools.

First, developers take advantage of the different services needed for each active learning session using objects created by the Runtime Factory. Figure 18 shows a sequence diagram with the steps the wrapper must follow to activate all needed objects. Steps 1, 4 and 7 represent calls to the introspection methods used to discover the actual information models coming from the first level of standardization that this particular implementation of CORBAlearn is able to deal with.


Figure 18: Steps to activate objects involved in a learning session


Among the features this subsystem offers to the wrapper we can mention:


Figure 19: SCO tracking and runtime data model communication



Figure 20: Learner interface showing the course TOC



Figure 21: Sequence to deliver a customized Table of Contents



Figure 22: User interface to introduce learner preferences


  • Predictive navigation. Navigation through course contents complemented with on-the-fly checking of requirements can be used to implement predictive navigation. A set of learning objects may be downloaded while the Learner is using a previous object provided by the wrapper. Once the Learner exits the first one, the wrapper is prepared to a prompt execution of the next one according to the course structure. Methods are provided to check access permissions without actual content download. Figure 23 presents the sequence diagram that must be followed by the wrapper. We assume the first learning object has been launched before step 1, where this fact is tracked. During the execution of this object, the wrapper requests the next SCO in the course structure (step 2). We assume at step 3, where first learning object is evaluated by the CORBAlearn implementation, that downloading has finished. Before executing the next learning object, the wrapper checks if all requirements have been successfully fulfilled (step 4). In that case, exit from the first learning object (step 5) and execution of the next one is tracked (step 6).


Figure 23: Predictive navigation using CORBAlearn services


As identified by the Reference Architecture, c.f. section 3.3, the RuntimeEnvironment subsystem depends on the services provided by other fundamental subsystems in the ESP, namely CourseRepository and LearnerAdministration (c.f. Figure 24). The first one is needed to access the learning objects that must be sent to the learners, and to access static structure and dynamic behavior for those contents. The second one is needed for accessing Learner preferences and forupdating Learner transcripts when he or she masters the contents. These subsystems can be part of the same ESP as the RuntimeEnvironment (left side of Figure 24) or may be distributed in different, and possibly developed by different vendors, heterogeneous e-learning systems (ESPs). As for the car manufacturing example (c.f. Figure 4), interoperability is guaranteed as these subsystems provide the same interface regardless the vendor that developed them: CORBAlearn interfaces.


Figure 24: Possibilities for the RuntimeEnvironment Implementation



The first part of this paper discusses the current state of the e-learning standardization process. While the first level of standardization, which deals with specifications for information models, is mature enough with some de-facto standards available, the second level, which deals with definition of architectures and software interfaces, is still in its infancy and there is a lot of work to do.

In this line, this paper contributes to the e-learning standardization at the second level, defining a Reference Architecture and particular interface specifications for the business logic tier of a distributed online education environment.

The Reference Architecture proposed is conceptual and implementation independent, and may be instantiated for different technological infrastructures. It is composed of a set of reusable subsystems that provide fundamental services to build final applications. Defined services are the consequence of the strict application of a systematic methodology to obtain service architectures. Components defined can be easily identified by those agents involved in the e-learning standardization process, as they encapsulate different standardized information models in separate subsystems. This property, together with the separation of functional requirements, makes our architecture oriented to local changes, and able to support the development of new systems in a scalable way.

It can be argued that this approach is too business process oriented, and results may be manifestly different if the process where based on a learner-centric approach. However, the foundation of the methodological process leading to CORBAlearn is based on use cases from relevant actors, the learner being one of them, perhaps the most important as the eventual objective of any learning initiative. This approach guarantees that the learner’s perspective is taken into account along the process in an integral manner, taking into account other actors’ needs.

Additionally, there are other relevant proposals that are more pedagogically driven, which in this aspect complement the stance supported in this paper. In [53], the Open Knowledge Initiative from Stanford University proposes an API-based  infrastructure for educational application development and support that is learner-centered in conception. As another example, the approach from the Learning Systems Architecture Lab in Carnegie Mellon [54] advocates for  an architecture for user-centric learning management systems, aimed to a virtual university.

Concrete software interfaces are defined as a proposal for a new domain CORBA facility for e-learning: CORBAlearn. CORBAlearn includes the definition of data structures to encapsulate outcomes from the first level of standardization, exceptions and service interfaces, which are distributed among 13 different specifications that cover the whole spectrum of functionalities included in full-fledged e-learning environments. Open publication of these interfaces within the OMG framework will assure interoperability among products developed by different vendors, provided they are built over CORBAlearn-compliant products. Also, software reuse is promoted as new systems can be built over components offering the basic and fundamental services defined by the CORBAlearn specifications. CORBAlearn specifications are compatible with current available standards for the first level of standardization. Information models defined by standards at that level are properly managed and transferred using CORBAlearn-compliant products, with no tie to any specific proposal. Therefore, this contribution to the second level in the e-learning standardization process supports both reuse and interoperability, not only at the back end, but also at the business logic tier.


We want to thank Xunta de Galicia for its support through project PGIDT00TIC32203PR "Arquitecturas Distribuidas para Teleservicios ", engineers Juan Aguiar, Diego Conde, Fernando Gómez and Jorge Domínguez for their contribution to the development phase of CORBAlearn. Also, we want to thank the anonymous reviewers for their valuable comments.


  1. Learning Technologies Standardization Committee (LTSC). Web site at http://ltsc.ieee.org [Last access November 23th, 2001]
  2. IMS Global Learning Consortium. Web site at http://www.imsproject.org [Last access November 23th, 2001]
  3. Aviation Industry Computer Based Training Committee. Web site at http://www.aicc.org [Last access November 23th, 2001]
  4. US Department of Defense, Advanced Distributed Learning (ADL) Initiative. Web site at http://www.adlnet.org [Last access November 23th, 2001]
  5. The Alliance of Remote Instructional Authoring and Distribution Networks for Europe (ARIADNE). Web site at http://ariadne.unil.ch [Last access November 23th, 2001]
  6. Getting Educational Systems Talking Across Leading Edge Technologies (GESTALT) project. Web site at http://www.fdgroup.co.uk/gestalt [Last access November 23th, 2001]
  7. PROmoting Multimedia access to Education and Training in EUropean Society (PROMETEUS). Web site at http://prometeus.org [Last access November 23th, 2001]
  8. European Committee for Standardization (CEN), Information Society Standardization Systems (ISSS), Learning Technologies Workshop (LT). Web site at http://www.cenorm.be/isss/Workshop/lt/ [Last access November 23th, 2001]
  9. Gateway to Educational Materials (GEM). Web site at http://www.geminfo.org [Last access November 23th, 2001]
  10. Educational Network Australia (EdNA). Web site at http://www.edna.edu.au [Last access November 23th, 2001]
  11. International Standardization Organization (ISO)/Institute Electrotechnical Commission Committee for Learning Technologies (ISO/IEC JTC1 SC36). Web site at http://www.jtc1sc36.org [Last access November 23th, 2001]
  12. L. Bass, P. Clements, and R. Kazman. "Software Architecture in Practice". Addison-Wesley, April 1999.
  13. AICC Guidelines and Recommendations. "Icon Guidelines". Version 1.0. Technical report, Aviation Industry CBT Committee, 1996. Electronic version available at http://www.aicc.org/docs/AGRs/agr009.zip [Last access November 23th, 2001]
  14. T. Bray, J. Paoli, and E. Maler. "Extensible Markup Language". Technical report, W3C, 2000. Electronic version available at http://www.w3.org/xml/ [Last access November 23th, 2001]
  15. W. Hodgins. "Draft Standard for Learning Object Metadata (LOM) Specification". Proposed Draft 6.1, Institute of Electrical and Electronics Engineers, Inc., 2001. Electronic version available at http://ltsc.ieee.org/doc/wg12/LOM_WD6-1_1_without_tracking.pdf [Last access November 23th, 2001]
  16. L. Anido, M.J. Fernández, M. Caeiro, J.M. Santos, J.S. Rodríguez, M. Llamas. "Educational Metadata and Brokerage for Learning Resources". Computers and Education. [To appear]. Electronic version available at http://www-gist.det.uvigo.es/~lanido/congresos/lanidoCompEduc.zip [Last access November 23th, 2001]
  17. F. Farance. "Draft Standard for Learning Technology. Public and Private Information (PAPI) for Learners (PAPI Learner)". Technical report, Institute of Electrical and Electronics Engineers, Inc., November 2000. Electronic version available at http://edutool.com/papi/papi_learner_07_main.pdf [Last access November 23th, 2001]
  18. C. Smythe, F. Tansey, and R. Robson. "IMS Learner Information Packaging Information Model Specification". Version 1.0. Technical report, IMS Global Learning Consortium, 2001. Electronic version available at http://www.imsproject.org/profiles/lipinfo01.html [Last access November 23th, 2001]
  19. G. Collier and W. Veres. "IMS Enterprise Information Model". Version 1.01. Technical report, IMS Global Learning Consortium, 2001. Electronic version available at http://www.imsproject.org/enterprise/eninfo03.html [Last access November 23th, 2001]
  20. J. Hyde. "CMI Guidelines for Interoperability". Version 3.4. Technical report, Aviation Industry CBT Committee, 2000. Electronic version available at http://www.aicc.org/docs/tech/cmi001v3-4.pdf [Last access November 23th, 2001]
  21. P. Dodds. "Sharable Content Object Reference Model (SCORM)". Version 1.2. Technical report, Advanced Distributed Learning Initiative, January 2001. Electronic version available at http://www.adlnet.org/Scorm/downloads.cfm#spec [Last access November 23th, 2001]
  22. T. Anderson and M. McKell. "IMS Content Packaging Information Model". Version 1.2. Technical report, IMS Global Learning Consortium, 2001. Electronic version available at http://www.imsproject.org/content/packaging/cpv1p1p2/imscp_infov1p1p2.html [Last access November 23th, 2001]
  23. C. Smythe, E. Shepherd, L. Brewer and S. Lay. "IMS Question & Test Interoperability Overview". Version 1.2. Technical report, 2001. IMS Global Learning Consortium, Inc, Electronic version available at http://www.imsproject.org/question/qtiv1p2pd/imsqti_oviewv1p2.html [Last access November 23th, 2001]
  24. L. Anido-Rifón, M. J. Fernández-Iglesias, M. Caeiro-Rodríguez, J. M. Santos-Gago, J. Ródríguez-Estévez, M. Llamas-Nistal. "Virtual Learning and Computer Based Training Standardization. Issues and Trends". Submitted to ACM Computing Surveys. Electronic version available at http://www-gist.det.uvigo.es/~lanido/congresos/anidoSurveys.zip [Last access November 23th, 2001]
  25. Placewere Conference Center. Web site at http://www.placeware.com [Last access November 23th, 2001]
  26. Centra99. Web site at http://www.centra.com [Last access November 23th, 2001]
  27. Courseinfo. Web site at http://www.blackboard.net/courseinfo [Last access November 23th, 2001]
  28. WebCT. Web site at http://www.webct.com [Last access November 23th, 2001]
  29. Docent. Web site at http://www.docent.com [Last access November 23th, 2001]
  30. ISOPIA's ILMS. Web site at http://www.isopia.com [Last access November 23th, 2001]
  31. Knowledgesoft LOIS. Web site at http://www.knowledgesoft.com/ [Last access November 23th, 2001]
  32. F. Farance and J. Tonkel (Technical Editors). "Draft Standard for Learning Technologies. Learning Technology Systems Architecture (LTSA)". Technical report, IEEE Inc., November 2001. Electronic version available at http://ltsc.ieee.org/doc/wg1/IEEE_1484_01_D09pre_LTSA--20011115--no_tracking.pdf [Last access November 23th, 2001]
  33. V. Wade, K. Riley, B. Banks, P. Foster, N. Evans-Mudie, Y. Nicol, and P. Doherty. "Work Package 5: Object (Interfaces) Specification". GESTALT, 1999. Electronic version available at http://www.fdgroup.co.uk/gestalt/D502v4.zip [Last access November 23th, 2001]
  34. ACTS projects. Web site at http://www.infowin.org/ACTS/ [Last access November 23th, 2001]
  35. Object Management Group. "Common Object Request Broker: Architecture and Specification". Revision 2.5, OMG, September 2001. Electronic version available at http://www.omg.org/cgi-bin/doc?formal/01-09-34 [Last access November 23th, 2001]
  36. Object Management Group (OMG). Web site at http://www.omg.org [Last access November 23th, 2001]
  37. CORBA Services. Information available at http://www.omg.org/technology/documents/formal/corbaservices.htm [Last access November 23th, 2001]
  38. CORBA Domain Specifications. Information available at http://www.omg.org/technology/documents/spec_catalog.htm#domain%20specs [Last access November 23th, 2001]
  39. I. Jacobson, G.Booch, and J.Rumbaugh. "The Unified Software Development Process". Addison-Wesley, 1999.
  40. I. Jacobson, G. Booch, and J. Rumbaugh. "The Unified Modelling Language User Guide". Addison Wesley Longman, 1999.
  41. Object Management Group. "UML Profile for CORBA Specification". Technical report, OMG, October 2000. Electronic version available at ftp://ftp.omg.org/pub/docs/ptc/00-10-01.pdf [Last access November 23th, 2001]
  42. S. Fredrickson. "Untangling a Tangled Web: An Overview of Web Based Instruction Programs". T.H.E Journal, 26:67-77, 1999
  43. S. Landon. "Comparative Analysis of On-line Educational Delivery Applications". Technical Report, 2001. Electronic version available at http://www.ctt.bc.ca/landonline [Last access November 23th, 2001]
  44. L. Anido, M. Llamas and M.J. Fernández. "Labware for the Internet". Computer Applications in Engineering Education 8(3-4):201-208, 2000
  45. L. Anido, M. Llamas and M.J. Fernández. "Internet-based learning by doing". IEEE Transactions on Education 44(2):Accompanying CD-ROM, 2001
  46. L. Anido, M. Llamas and M.J. Fernández. "Developing WWW-based highly interactive and collaborative applications using software components". Software-Practice and Experience, 31(9), 2001
  47. F.J. González-Castaño, L. Anido, J. Vales, M.J. Fernández, M. Llamas, P. Rodríguez and J.M. Pousada. "Internet access to real equipment at computer architecture laboratories using the Java/CORBA paradigm". Computers & Education, 36:151-170, 2001
  48. R. Lindner. "Expertise and Role Identification for Learning Environments (ERILE)", 2001. Electronic version available at http://jtc1sc36.org/doc/36N0065.pdf [Last access November 23th, 2001]
  49. L. Anido, M. Llamas, M.J. Fernández, J. Rodríguez, J. Santos and M. Caeiro. "A Conceptual Modelling Framework for Standards-Driven Web-Based Distance Learning", ER2001, Lecture Notes on Computer Science (LNCS), 2001[publication pending]. Electronic version available at http://alen.ait.uvigo.es/~lanido/congresos/anido_er.zip [Last access November 23th, 2001]
  50. F. Dawson and T. Howes. "vCard MIME Directory Profile", Technical Report, Internet Engineering Task Force, 1998. Electronic version available at http://www.ietf.org/rfc/rfc2426.txt [Last access November 23th, 2001]
  51. B. Banks et al. "D0201: Gestalt Joint Requirements Specification", GESTALT project, 1998. Electronic version available at http://www.fdgroup.co.uk/gestalt/d201v2.zip [Last access November 23th, 2001]
  52. L. Anido. "Contribución a la Definición de Arquitecturas Distribuidas para Sistemas de Aprendizaje Basados en Ordenador utilizando CORBA", Ph.D. Thesis, Departamento de Ingeniería Telemática, Universidad de Vigo, 2001
  53. Open Knowledge Initiative. Massachusetts Institute of Technology. Web site at http://web.mit.edu/oki [Last access February 27th, 2002]
  54. Learning Systems Architecture Lab. Architecture for User-Centric Learning Management Systems.Carnegie Mellon University. Web site at http://www.lsal.cmu.edu [Last access February 27th, 2002]


Luis E. Anido-Rifón received the Telecommunication Engineering (1997) degree from the University of Vigo with Honors by the Spanish Department of Science and Education and by the Galician Regional Government. He has been also awarded by the Galician Royal Academy of Sciences. He joined the Telecommunication Engineering faculty of the University of Vigo where he is working towards his PhD. His main interests are in the field of New Information Technologies applied to distance learning and in the area of Object-oriented distributed systems. Actually, he participates in two CEN Workshops devoted to LOM internationalization and to the definition of learn-related vocabularies and taxonomies, respectively.

Juan M. Santos-Gago is a Telecommunication Engineer (1998). He has been involved in several projects related to distance learning and e-commerce. Now, he is Assistant Professor at the University of Vigo.

Judith S. Ródríguez-Estévez received her Telecommunication Engineering (1999) degree from the University of Vigo. In addition to teaching, her main interests are in the Educational Metadata and Information Retrieval.

Manuel Caeiro-Rodríguez received the Telecommunication Engineering (1999) degree from the University of Vigo. Currently, he teaches Computer Architecture and Software Engineering at the Telecommunication School where he is working towards his PhD.

Manuel J. Fernández-Iglesias graduated from the University of Santiago de Compostela, Spain, with a Telecommunication Engineering degree in 1990, and from University of Vigo with a Doctor in Telecommunication degree in 1997. He is actively involved in researching in the area of multimedia applications, Computer Based Training and Formal Description Techniques.

Martín Llamas-Nistal received the Telecommunication Engineering (1986) and Doctor in Telecommunications (1994) degrees from the Technical University of Madrid, Spain. He is the head of the GIST research group and New Technologies Division at the University of Vigo.