IMS Abstract Framework: White Paper
Version 1.0
|
IMS Abstract Framework: White Paper Version 1.0 |
Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Abstract Framework: White Paper
Revision: 01 July 2003
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2003 IMS Global Learning Consortium. All Rights Reserved.
If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.
This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
The IMS Abstract Framework is a device to enable the IMS to describe the context within which it develops its eLearning technology specifications. This framework is not an attempt to define the IMS architecture, rather it is a mechanism to define the set of interfaces for which IMS may or may not produce a set of interoperability specifications. The IMS Abstract Framework is so named because:
It is the intention of IMS that this Abstract Framework and the associated IMS specifications produced to realize the exchange of information between the identified services will be adopted in a manner suitable for a particular system requirement. The Abstract Framework is represented as a layered model, as shown in the figures below; this approach was derived from an extensive survey of the state-of-the-art for eLearning architectures.
The core features of the framework are:
The IMS specifications are used to define the data structures, and when appropriate the permitted behaviors for the exchange of those data structures, between the Components. This interoperability is defined in terms of the exchange of the appropriate XML instances as defined by their XML Schema Definitions. The IMS specification of a service is such that any number of bindings can be created e.g., native XML, web services description language, Java, etc. It is the corresponding information and behavioral descriptions that enable interoperability between these different bindings. The Abstract Framework also describes the transport mechanisms that can be used to exchange the XML documents.
The adoption of the Abstract Framework will be based upon the creation of suitable Domain Profiles. Domain profiling is the process that is undertaken to define which specifications and the detailed usage of the data objects within each specification are to be adopted to provide a particular solution. The domain profiling process is based upon:
This is a 'living' document i.e., it is not archival in nature. Our ideas for various parts of the Abstract Framework are constantly being developed and so the information contained herein should always be considered in that context. This white paper is one of a set of closely related documents, the others being:
'Domain Conformance' will not be defined with respect to an IMS specification. These specifications contain too many optional features and are subject to regional and sector specific amendments e.g., the inclusion of the appropriate vocabularies. Therefore, conformance will be against a particular Conformance Profile that has been derived from the corresponding Domain Profile. Conformance certification is considerably easier when all of the functionality is mandatory and so it is important for Conformance Profiles to remove as much optional functionality as possible. In turn, there is a generic requirement that for a Domain Profile to be 'Strictly Conforming' to an IMS specification then an XML instance of the domain profile must also validate against the corresponding IMS specification.
The IMS Abstract Framework (IAF) is a device to enable the IMS to describe the context within which it will continue to develop its eLearning technology interoperability specifications. This framework is not an attempt to define the IMS architecture, rather it is mechanism to define the set of interfaces for which IMS may or may not produce a set of interoperability specifications. In the cases where IMS does not produce a specification then every effort will be made to adopt or recommend a suitable specification from another organization. The IMS Abstract Framework is so named because:
It is the intention of IMS that this Abstract Framework and the associated IMS specifications will be used as the starting point for the definition of many different eLearning systems. Each eLearning system will only adopt those parts of the IMS specifications that are of immediate use. This process is called the Profiling of the framework to define an architecture or reference model for a particular implementation domain; the process of profiling a particular specification is similar to refining the best practice to produce mandatory facets for an implementation domain. The Profiles can then be used to support conformance testing, based upon a particular conformance-profile for that domain, to ensure compliance to a particular requirement.
This is a 'living' document i.e., it is not archival in nature1. Our ideas for various parts of the IAF are constantly being developed and so the information contained herein should always be considered in that context. This white paper is one of a set of closely related documents, the others being:
At the current time only the Glossary and the Application, Services, and Components documents are available as support to this white paper. During the next twelve months the other documents will become available and consequently new releases of the IAF may be required. This white paper is constructed in three sections:
The IAF provides the context for the development of the next series of IMS specifications. The IMS specification development process uses the IAF to:
As with all of the IMS specifications there is a need to develop best practice for each of the activities summarized above. The IAF will be updated on a regular basis, typically once every six months, and as a part of other activities e.g., development of the learning activity model. While these updates will include important new information, the underlying principles of interoperable, component-based service definitions within a layered framework will not be changed.
The structure of this document is:
During the past 30 months IMS has released a unique set of interoperability specifications within the eLearning technology community (that work was founded upon an extensive range of experimental activities undertaken during the prior 24 months). During this period the various eLearning technology activities have begun a slow convergence that has been the result of extensive work behind the scenes by IMS and other organizations. It is now apparent that the current set of IMS activities and processes need to evolve to tackle the next series of technical issues [IMS, 02a]. As a consequence, IMS has produced its Abstract Framework to the context within which:
The current set of IMS specifications released and under development is listed in Table 2.1.
The IMS also has a set of guidelines that have been released to act as support documents to the specifications. These guidelines are:
The specifications are focussed on the exchange of information between systems. The specifications make no assumptions on how the data is managed within the communicating systems.
The exchange between the systems is to be defined in terms of the services being supplied by the collaboration of the systems. This service collaboration could take many forms as well as being based upon peer-to-peer and client-server techniques.
The set of services will be supplied as a 'sea of components' that can be mixed and matched to form a particular service. A single component may provide all or a sub-set of a service but it will not provide more than one service.
The total set of services required to make an eLearning system will be modelled as a set of layers with each layer providing a clearly defined set of services. A particular layer will make use of the services in the layer below it and will provide services to the entities in the layers above it.
A service will be defined in terms of its behaviors and data model. The behaviors will cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behavior. It may not be appropriate to define every service in terms of its behavior and in these cases only the relevant data models will be developed.
The information model is to be defined and represented using an established syntax and semantics. This will then enable automatic mapping of the information model into a range of different bindings. The bindings of immediate importance are XML and Web Services Description Language (WSDL), however Java bindings will also be supported.
New specifications will only be created as required. Whenever possible, appropriate specifications will be adopted from wherever and either used 'as is' or modified to suit a particular set of requirements.
The service range covered by the abstract framework is based upon a core set of use cases that have been collected from:
In all cases these use cases have been taken from different parts of the world, with a particular focus on North America, Europe and Asia. This ensures that the internationalization aspects of eLearning services are considered.
Note: The Use Case Portfolio activity currently underway will complete its work in late 2003. That portfolio will be used as the basis for further material in this sub-section. The key use cases will be used to identify the set of applications and services that need to be supported.
The scope of the abstract framework is set by the requirements generating by analyzing:
Note: The Use Case Portfolio activity currently underway will complete its work in late 2003. That portfolio will be used as the basis for further material in this sub-section.
A review of a wide range of eLearning systems is summarized in Appendix C and a synthesis of these is shown in Figure 3.1. Figure 3.1 is a logical architecture based upon layer abstraction. The equivalent physical architectural model is shown in Figure 3.2.
The logical representation consists of the following layers:
The physical representation (Figure 3.2) consists of the following core structures:
The abstract framework has to be designed such that it can be used to represent a wide range of architectures.
There are several possible functional perspectives of an eLearning system. The two perspectives that are introduced herein are (it is these perspectives that dominate the IMS specification activity):
These functional perspectives identify where the interoperability points are within an eLearning system i.e., where the arrows are used in Figures 3.3 and 3.4. If these exchange points are exposed as external communications between different systems then an interoperability specification is required.
A functional representation of the flow and management of content and related information within an eLearning system is shown in Figure 3.3.
There are four key functional themes:
A functional representation of the flow and management of personal and related information within an eLearning system is shown in Figure 3.4
Again, there are four key functional themes:
The abstract learning framework can be represented as a layered model, as shown in Figure 3.5, consisting of four layers:
Access to a service is through the appropriate Service Access Point (SAP). Each service has a single SAP. A Component may support one or more SAPs (in an object oriented representation, a SAP could be supported by one or more operators where the class is itself the definition of the service).
In a distributed implementation of this layered framework, as typified in a webs services environment, the interaction between the services would as shown in Figure 3.6. In this interaction framework there are three categories of interface that must be supported by the Infrastructure layer namely:
Figure 3.6 shows that there are two types of interaction behavior that need to be specified to ensure interoperability, namely:
One of the design principles for the IAF is the adoption of service abstraction to describe the appropriate eLearning functionality. The service is hidden behind a SAP and can only be accessed by using the SAP (an API could be one way in which the SAP is actually implemented). However, even though the service provision is hidden behind the SAP, an implementation requires that the behavioral capabilities of the service be defined. Once again an object-oriented representation is adopted. In Figure 3.7 we have a schematic representation of a service, namely:
This approach means that every service (application and common) must be defined using this form of abstraction. In many cases the services interact with each other e.g., an application service will use a common service. This interaction is reflected by the service invoking the SAP of the required service.
The adoption of UML as our representation framework means that each service must be defined by:
Few of the current IMS specifications address the issue of content run-time interoperability. This is handled by other specifications e.g., the AICC CMI. However, IMS need to look at several run-time issues such as content-to-content communication, web service based content launch, etc. A schematic representation of the run-time architecture for content is shown in Figure 3.8.
Figure 3.8 shows that the interactions between a content server (LMS, LCMS, etc.) and the delivery clients (typically this includes the usage of a browser); note that in general the server will have a significant number of concurrent users who will be using different learning materials and who may or may not wish to halt and restart their activities at various times. The client should be able to 'pull-in' other content as and when required without requiring communication through the server. The client should also be able to launch multiple concurrent 'learning objects' that co-operate to provide the full learning experience. Therefore the client will need a range of plug-ins that will enable it to parse the content, render the content, etc. before actually playing the material to the user.
This scenario requires clear definition of the internal behaviors of the server and client in response to the user's interactions with the content. The nature of the content being exchanged between the server and client needs to be addressed - at present this is either web pages with or without other material that can be played with the appropriate plug-in or it is executables that can run natively on the client device. The increasing adoption of XML may mean that it is possible to encode content natively in XML - clearly not all content will be XML encoded e.g., video.
The layered representation shown for the IAF in Figure 3.5 can be redrawn in UML as shown in Figure 3.9. In many regards this is a more appropriate representation as the IAF does not enforce a robust layering in the way that it can be implemented.
The object oriented representation in Figure 3.9 shows the dependence between the different 'layers' or the services.
The set of applications, services and components that can be developed using this abstract framework are detailed in [IMS, 03b]. In this Section we are going to describe the characteristics that are used to categorize an application, application service, common service and component.
In the context of eLearning, an application is the manifestation of a system or tool that delivers one or more eLearning application services to a user. The key differences between an application and an application service are that an application provides an interface to the user(s) and that it may use more than one application service. A template for the brief description of an application is shown in Table 4.1.
Note: IMS will not be undertaking the specification of applications as a part of its specification development activity.
In the context of eLearning, an application service is responsible for delivering a set of features that support the manipulation of a set of data objects for a common purpose e.g., an Assessment Service for online assessment. An application service may be created by aggregating other application services. A template for the brief description of an application service is shown in Table 4.2.
Note: The core specification development activity undertaken by IMS will focus on the development of application services.
A common service is responsible for delivering a set of features that are relevant to more than one application service and which, in many cases, are also required by non-eLearning systems e.g., an authentication service. A template for the brief description of a common service is shown in Table 4.3.
Note: IMS will not be undertaking the specification of common services as a part of its specification development activity.
A component is the realization of an abstract model. IMS produces specifications of services that can be released as components that provide interoperability capabilities for eLearning systems. A template for the brief description of a component is shown in Table 4.4.
An IMS specification of a component is the UML-based representation of the abstract application programming interface. This representation describes the set of classes for the component and defines the data and information that is exchanged between the corresponding objects.
The IMS specifications are focused on data exchange interoperability. To this end they define a data model of the information to be exchanged and a behavioral model that encapsulates the data model and constrains the way in which the data can be manipulated. An IMS information model is the manifestation of this behavioral and data description and an information model will consist of one or more IMS Components (these will realize either all, or part of, an Application Service). These components can then be realized in a variety of ways; the defined IMS method is as an XML-based binding. As such, this binding describes the way in which the data is exchanged in the form of XML messages/documents, however the actual transfer of these structures requires, at the very least, an appropriate communications system.
The exchange of the data between the XML components within the abstract framework is defined through the Infrastructure Layer. A schematic representation of the system components in this infrastructure description is shown in Figure 5.1. This representation assumes that the system is loosely coupled e.g., as per web services.
In Figure 5.1 the key parts of this infrastructure are:
The XML-based Context sub-layer is responsible for mapping the behaviors and associated operators of the XML components onto an appropriate sequence of XML messages. In principle there are a very large number of possible operators for even just a few components. There is however a number of common operators as described in Table 5.1. Table 5.1, or the Beshears Matrix (taken from work produced by the Enterprise working-group) was derived to identify the generic types of operation/methods required to enable the exchange of objects between an initiating system (initiator) and the responding system (respondent).
The corresponding state diagram requires that the completion of each method should be accompanied by the definition of which of the next methods can be invoked successfully on the same object.
The set of XML messages required to support the operators in Table 5.1 must include the following range of functionality:
Any of the messages may consist of the actual control and core data structures plus any associated resources e.g., jpeg files, etc.
The equivalent state diagram for the operators shown in Table 5.1 is given in Figure 5.2.
The start state is when the system is idle. An instance of an object can then be created one of three ways:
Once the object has been created all operations are now supported. Once the delete operation has been invoked the object is deleted and the system returns to the 'Idle' state. In Figure 5.2, it is assumed that the state of the operation is reported to the system initiating the operation.
In the case of loosely coupled systems then the Beshears matrix is implemented by the exchange of messages. In most cases this is a two-phase message exchange with the initiator of the interaction issuing the 'request' message and the respondent replying with the 'response' message; this is normally termed the 'request-response' service model. It is good practice to ensure that the response message carries back the state of the initial request i.e., was the request successfully process or not and if not what was the cause for the failure. Table 5.2 shows the types of information that should be sent in the request/response messages. The various status codes include:
WSDL is one representation method for the context sub-layer. This enables the operations and their associated logical messages to be expressed in XML but it also provides the binding of those messages to the equivalent transport mechanism (the envelope sub-layer). In the case of SOAP the XML message is carried in the body part of the SOAP message is defined using an XSD. A brief overview of WSDL is given in the IMS specification development methods and best practices guide [SpecDev, 03].
The XML-based Envelope sub-layer is responsible for encapsulating the sequence of XML messages and associated resources produced by the XML-based Context sub-layer in a common XML messaging structure. The three available approaches are:
The Simple Object Access Protocol (SOAP) is a messaging transport protocol that can be implemented using XML documents [SOAP, 03a], [SOAP, 03b], [SOAP, 03c]. A brief overview of SOAP is given in the IMS specification development methods and best practices guide [SpecDev, 03].
SOAP with Attachments is an extension of SOAP that is designed to enable non-XML information to be transported in the SOAP messages [SOAP, 01a]. A brief overview of SOAP is given in the IMS specification development methods and best practices guide [SpecDev, 03].
The XML-based replacement of the Electronic Data Interchange (EDI) is termed ebXML. ebXML is based upon an extensive range of functionality ranging from the transaction exchange mechanisms to the routing table protocols [ebXML, 01a], [ebXML, 01b], [ebXML, 01c], [ebXML, 01d], [ebXML, 01e], [ebXML, 01f], [ebXML, 01g].
The Generic Transport sub-layer is responsible for transferring the XML messages across the appropriate data network architecture. The specification of these protocols is outside the scope of the abstract framework with the exception of ensuring that the XML-based Envelope sub-layer XML messages can be exchanged using the appropriate generic transport protocol. The detailed sub-structure of the generic transport sub-layer is:
A working system requires the profiling of the entire infrastructure layer to support the appropriate application and common services. IMS will be producing a series of recommendations for a set of default infrastructure profiles as a part of its general web services binding project (to be completed by the end of 2003). One of the strengths of this layered approach is that the information model definition remains unchanged for different infrastructure profiles as it is the only the binding to that infrastructure that must be changed. Also, one infrastructure profile is capable of supporting many different information models provided the infrastructure sustains the minimum quality of service capabilities e.g., reliable end-to-end data delivery.
The abstract framework is formally expressed as a UML representation. From an IMS perspective, this information model representation is traditionally bound to XML. In the new specifications XML will not be the only supported binding. This representation process is shown in Figures 6.1.
In Figure 6.1 it is shown that the logical representation of a system is derived from one or more classes that are grouped using packages. The package shows the dependencies between the classes. Each class consists of attributes (the data structures) and operators (the operations permitted on the data structures). The system is then constructed from these components as shown in the deployment diagram. The logical structure is represented using packages and it is representation that must be mapped using an appropriate binding. The advantage of this approach is that both the UML specification (the Information Model) and the corresponding set of bindings (of which XML and WSDL are just two) can be used for implementation. It is then possible to map together different implementations in different ways without loss of capability. The usage of an information model defines the common service capability between the different bindings.
The binding must take into account the attributes and operators of the class. In the original IMS specifications the XML DTDs and XSDs were a representation of the attributes of the class. The behavioral representations are defined through the class operators. In this case the binding is achieved by representing these operators as a series of messages exchanged by the communicating eLearning systems. The behavior is represented by the sequence of messages and the content of the control field in the headers of the messages (a message is assumed to consist of a header, containing the control fields, and the body, containing the data to be transferred).
A simple system showing the exchange of an object between two systems (the initiator and the respondent) is shown in Figure 6.2. In this system the initiator is requesting that the respondent create an object. In the initiator the 'createObject()' operator is invoked. The implementation of the object handler in the initiator translates this action into a 'createObject.request' XML message. This message is passed to the communications handler object that is responsible for transmitting this message to the respondent system via the communications network. The respondent communication handler may be required (this depends upon the protocol being implemented) to return an acknowledgment message that is used to inform the initiator that the request has been received. When the respondent actually completes the object creation request, notification of this may be returned to the initiator. This notification results in the transmission of the 'createObject.response' message. Its receipt at the initiator signifies that the request has been completed; this may or may not have resulted in the creation of the object and so some completion status codes should be returned via the 'createObject.response' message.
This sequence gives rise to three categories of information exchange, namely:
From the perspective of the fully layered abstract framework one possible sequence of events is as shown in Figure 6.3. In this scenario two systems (perhaps Enterprise systems) are exchanging information e.g., the initiator wishes to inform the respondent of the creation of a group. The systems use a common application service and one common service e.g., authorization. The infrastructure service underpins all of the other services and provides a reliable end-to-end communication infrastructure. The initiator is using remote services and as such the initiating objects must contain the interface definitions for the service. The respondent objects must contain the functionality to actual handle the service requests.
The initiating system issues the 'createObject()' which results in the object invoking the relevant application service. The application service issues the remote object creation instruction. This request requires the application service to obtain authorization though the corresponding common service. Once the authorization has been completed the actual object creation process is started and this request is sent to the respondent system. Once the request has been processed the appropriate response is returned to the initiator.
There are several ways in which this scenario could be developed:
It is important to stress that this scenario has been considered from the perspective of a generic binding of the services. The actual mapping is dependent on the nature of the services and the underlying capabilities in the Infrastructure Layer.
The advantage of using a robust method for representing the behavioral aspects of the information model means that, in principle, different bindings can be automatically generated by the usage of the appropriate tools and the application of suitable transformation rules. Figure 6.4 shows the set of possible bindings that can be created.
The key points from Figure 6.4 are:
The preferred IMS service binding approach is based upon:
It is possible to translate between different IMS bindings provided the binding of the information model has been reliably and consisted. This gives rise to the following forms of communications interoperability issues:
Domain profiling is the process that is undertaken to define which specifications and the detailed usage of the data objects within each specification are to be adopted to provide a particular solution. Therefore, the development of SCORM, using this terminology, was domain profiling undertaken on behalf of the US Department of Defense. In general, a resulting 'Domain Profile' or 'Reference Model' will be based upon a variety of specifications and standards i.e., it will not consist, solely, of IMS specifications.
The domain profiling process is based upon:
The issue now becomes one of how to map between different domain profiles i.e., this is inter-domain interoperability (the domain profile supports intra-domain interoperability. In many cases different domain profiles will have a common core with only a small set of important differences. Mapping between domain profiles is simplified due to the usage of XML as the binding format. The mapping process is shown schematically in Figure 7.1 in which there are two, currently theoretical, domain profiles of QTI for SCORM and SIF. Each domain profile has its own XML schema that is the manifestation of the domain profile of the IMS QTI specification. These schemas are then used to validate the QTI-XML documents for the corresponding application profile. In each case the domain profile would be used by an appropriate system e.g., a SIF LMS (it is possible that a single LMS could in fact support both the SCORM and SIF domain profiles).
The advantage of the usage of XSDs is that an XML Stylesheet Transformation (XSLT) can be used to support the transformation between the XSDs; there would be one XSLT for each QTI transformation i.e., SIF-to-SCORM and SCORM-to-SIF.
The XSLT can be defined to handle the mapping of each element and attribute in the XSDs, including those defined in any extension - each domain profile must define the information model and XML binding for all extensions. In some cases it will not be possible to map some features from one domain profile to similar features in the other. In these cases there is a loss of functionality but this is a controlled situation in that the situations under which this loss occurs is well understood.
'Domain Conformance' will not be defined with respect to an IMS specification. These specifications contain too many optional features and are subject to regional and sector specific amendments e.g., the inclusion of the appropriate vocabularies. Therefore, conformance will be against a particular Conformance Profile that has been derived from the corresponding Domain Profile. Conformance certification is considerably easier when all of the functionality is mandatory and so it is important for Conformance Profiles to remove as much optional functionality as possible.
The key issue for conformance under the first-generation specifications is that they were not designed from the perspective of being testable i.e., exhaustive testing to show compliance is possible but not cost effective. The reason for this is that the specifications are designed to support practice and not to impose a best practice. This has produce specifications that a largely based upon optional features and so the derived conformance profiles can have many disjoint features. The current specifications are data models and so the associated behaviors are assumed in the information model and not defined in a behavioral model. Once again this leads to important discrepancies in the underlying assumptions used by different application profiles.
Each of the first-generation specifications contains a conformance statement. In most cases these statements are either a simple statement of the obvious i.e., the insistence that the information is followed or consists of a tick list of the features that are supposedly supported. In neither case is it possible to use the statements as a definitive guide to the compliance or otherwise of an implementation to the corresponding IMS specification.
An underlying objective in the creation of the second-generation specifications is the creation of specifications against which conformance can be clearly shown. This means that the second-generation specifications must:
Unlike the first-generation specification the second-generation ones will contain an extensive conformance specification that will form the basis for conformance against which the application profiles will build.
The IMS specification roadmap given in Figure B1 shows the release sequence of the IMS specifications, AICC specifications, the IEEE standards and the key profiles. The arrows are used to denote instances where the IMS specifications have been adopted by a profile. The key for the IMS specifications is:
The core deliverable of the Open Knowledge Initiative (OKI) is an architectural specification in support of learning management and educational application development, the primary feature of which is a set of application programming interface (API) definitions. OKI are specifying the architecture by identifying a set of services, a framework, upon which learning tool developers can base their work. The goal here is twofold:
OKI is taking a layered approach to this architectural specification, defining a clean set of boundaries between the various required components that traditionally support learning applications. At the very lowest level of functionality OKI is building on existing work, within its partner institutions and elsewhere, to define an API layer of common services that will help institutions to integrate applications with existing institutional infrastructure. The OKI project is relatively unique in its vision that the issues of LMS architectural design should be approached as issues of institutional infrastructure.
As shown in Figure C1, the four layers from the bottom upwards are:
In Figure C1 the actual APIs are denoted as the interfaces to the implementations. The form of the implementations is beyond the scope of the OKI.
The deliverables from the OKI are the two sets of Java APIs for the Common Services and the Educational Services, namely:
While the OKI Architectural Specification is basically a document, it is the intention of MIT and some of its partners to actually develop implementations of these specifications in order to support OKI applications on their campuses.
MIT will make its implementations available as open source code via the IMS web-site, and other institutions may do the same as they see fit. Modularity at this level should allow sites installing OKI services to begin to pick and choose from among existing implementations where it makes sense. Therefore, it is expected that the OKI partner institutions initially, and eventually other institutions and vendors, will begin to share service level implementations. This will especially make sense for OKI services that currently have no counterpart in a typical institutional infrastructure. A good example of this might be the Rules service. Most sites do not currently have a Rules infrastructure and, therefore, may be more than happy to use someone else's.
However, it is expected that a number of services will require variations in local implementations to hook into existing or planned local infrastructure many different implementations of the Authentication (AuthN) and Authorization (AuthZ) services will be developed to interoperate with the various security infrastructures at our institutions.
The end goal of all of this is to encourage and support a wide range of pedagogical tool and educational application development activity and to allow these tools to be shared more easily among campuses. These pedagogical tools and applications are what the end users of OKI based systems will see and with which they will interact. In other words, users will never need to know about the framework underneath, they will simply reap the benefits of this integration through interoperable applications.
IMS and OKI are working closely together and several OKI members (MIT, University of Wisconsin, University of Michigan and Cambridge University) are IMS Contributing Members. During the development of the new IMS specifications the usage of the OKI Common Services will be described within the corresponding best practices and implementation guides. The IMS specifications of direct relevance to the OKI APIs are Enterprise Services, Digital Repositories Interoperability, Content Packaging, and Question & Test Interoperability.
The IEEE LTSA is an architecture based on abstract components - as shown in Figure C2 [IEEE, 02]. Higher-level abstractions can be "implemented" in lower levels: either lower level abstractions, or actual implementations. Learning technology systems ("implementations") can be mapped to/from LTSA.
The IEEE LTSA is pedagogically neutral, content-neutral, culturally neutral, platform/technology-neutral. It uses a simple "systems notation" i.e., processes ("bubbles" that transform information), stores (e.g., repositories and databases), flows (information between processes and stores). The abstract components of the IEEE LTSA are:
Note 1: The boundaries, functions, and decomposition of actual or other abstract learning technology systems might not have the same structure as LTSA, i.e., the mapping to LTSA might not be "one-to-one" (mathematical sense).
Note 2: Not all learning technology systems will have all components of LTSA, i.e., the mapping to LTSA might not be "onto" (mathematical sense).
Note 3: All inputs and outputs are optional to each process and store, e.g., the Evaluation process might or might not use Interaction Context as part of its processing; the Learning Resources might or might not have high quality Catalogue Information.
The IMS is one input channel to activities within the IEEE LTSC. In the future, the IEEE LTSC may or may not decide to adopt all or part of the abstract framework. The IEEE LTSC adopted IMS Meta-data and turned it into a standard.
The Sharable Content Object Reference Model (SCORM) defines web-based learning 'Content Aggregation Model' and 'Run-time Environment' for learning objects [ADL, 01a], [ADL, 01b], [ADL, 01c], [ADL, 02a], [ADL, 02b]. At its simplest, it is a model that references a set of interrelated technical specifications and guidelines designed to meet DoD's high-level requirements for Web-based learning content. The work of the ADL initiative to develop the SCORM is also a process to knit together disparate groups and interests. This reference model aims to co-ordinate emerging technologies and commercial/public implementations.
The SCORM applies current technology developments - from groups such as the IMS, the AICC, ARIADNE and the IEEEE LTSC - to a specific content model to produce recommendations for consistent implementations by the vendor community. At the current time SCORM V1.2 is the latest release but V1.3 is slated for release before the end of 2003. SCORM V1.3 will make use of the following specifications:
Within the SCORM, the generalized model of an LMS is shown in Figure C3. This model shows the potential components or services that are required of an LMS.
Within SCORM, the term LMS implies a server-based environment in which the intelligence resides for controlling the delivery of learning content to students. In other words, in the SCORM, the LMS has the ability to determine what to deliver and when, and track student progress through the learning content.
Even SCORM V1.3 will be missing some key functional eLearning capabilities and so the areas in which other IMS specifications could be used are:
The two core parts of SCORM are:
² SCORM Content Aggregation Model (SCAM) - this provides a common means for composing learning content from discoverable, reusable, sharable and interoperable sources. The SCAM further defines how learning content can be identified and described, aggregated into a course or portion of a course and moved between systems that may include LMSs and repositories. The SCAM defines the technical methods for accomplishing these processes. The model includes specifications for aggregating content and defining meta-data using the IMS Content Packaging and IMS Meta-data specifications respectively. The content is defined as a set of Assets which become Sharable Content Objects (SCOs) when the CMI launch and termination instructions are added. Sharable Content Assets (SCAs) are added as a part of SCORMv1.3;
² SCORM Run-time Environment (SRE) - the purpose of the SRE is to provide a means for interoperability between SCO based learning content and LMSs. A requirement of SCORM is that learning content be interoperable across multiple LMSs regardless of the tools used to create the content. For this to be possible, there must be a common way to start content, a common way for content to communicate with an LMS and predefined data elements that are exchanged between an LMS and content during its execution. The three components of the SRE are defined as 'Launch', API and Data Model.
SCORM is based upon several IMS specifications (Meta-data, Content Packaging, Simple Sequencing). ADL is an IMS Contributing Member and the SCORM project team make regular contributions to the development of the relevant IMS specifications.
One of the most pressing challenges for the K-12 education industry today is software interoperability: how to enable different software applications to share information in order to improve efficiency and reduce cost. To meet this challenge, many software companies in the education industry and educational institutions have spearheaded the Schools Interoperability Framework (SIF) initiative. SIF is an effort to promote interoperability between software applications from different vendors without requiring each vendor to learn and support the intricacies of other vendor's applications.
SIF has two deliverables: the SIF Implementation Specification v.1.0 and the notice of availability of one or more SIF compliant Zone Integration Servers [SIF, 00], [SIF, 01]. The Implementation Specification defines the software implementation guidelines for SIF. The Implementation Specification does not make any assumption of what hardware and software products need to be used to develop SIF compliant applications. Instead, it only defines the requirements of architecture, communication, software components, and interfaces between them. The goal of SIF is to ensure that all the SIF compliant applications can achieve interoperability, regardless of how they are implemented. SIF is truly an open industrial initiative. SIF Zone Integration Servers will be created by organizations for use on one or more hardware and operating system platforms. They are required to meet the requirements of the Implementation Specification and will be tested as being compliant with that specification but the specifics of the implementation and any additional features will be left to each developing organization to determine.
The target users of this document include software developers who develop SIF compliant products, technology specialists who deploy SIF solutions for K-12 institutions, and executive managers who need to evaluate the feasibility of SIF.
A SIF implementation must enable different applications to exchange data efficiently, reliably, and securely regardless of what platforms are hosting the applications. Nothing should be designed to preclude the specification implementation with any architecture. To this end HTTPS has been chosen as the default transport protocol for sending SIF's XML messages. HTTPS must always be supported in all SIF implementations. When HTTP and XML are used together in this way, a truly platform-neutral wire is created, over which any two SIF compliant applications can intercommunicate, independently of the language they are written in, and the operating system and hardware they are deployed on. The requirement of efficiency implies that the SIF implementation must support both real-time and batch data exchange between different applications. To achieve this goal, the communication mechanism for SIF must be efficient and lightweight. A SIF implementation should also scale to support large numbers of applications.
Reliability implies that when an application sends out a message destined for a receiver, the delivery of the message is guaranteed. This requirement also implies that messages sent by an application will arrive at the receiver in the same order as they were sent and that each message is delivered once and only once.
The SIF security requirement has three aspects, all of which may be optionally invoked by applications, and none of which may preclude compliant application interoperability:
SIF implementation is a distributed networking system that consists of a Zone Integration Server (ZIS) and one or more integration agents organized into a zone. The size of the zone is flexible and could consist of a single building, school, a small group of schools, a district, etc. SIF is a scalable solution to data exchange and supports multiple SIF implementations or zones. A ZIS is a program that provides integration services to all the agents registered with it so that they can provide data, subscribe to events, publish events, request for data, and respond to requests. It is responsible for all access control and routing within the system.
Each application server requires an agent, which typically is provided by the application vendor, to communicate with other application servers via their respective agents. For example, a school may use a student information application, a food service application, and a library automation application. Each of these applications must have an agent for their application that will act as a go-between between the application and the Zone Integration Server.
In SIF, an agent never talks to another agent directly. Instead, an agent communicates with its ZIS that will manage the connection to the other agent. By having the ZIS manage the routing responsibilities, it allows complex, multi-zone communications to occur between agents that have no direct information about the other. The ZIS acts as the trusted intermediary that brokers the data exchange. Figure C4 illustrates a typical single zone SIF implementation that reflects a single school zone.
In some SIF implementations, it may be necessary for SIF compliant applications to be organized into different zones based on the requirements of ownership, organizational structure, geographical proximity, security, or management. A zone is typically defined according to physical boundaries; for example, a zone can consist of all the applications that are connected over a private network and managed by one organization, such as a school. A ZIS is required in each zone and each application server requires an agent to connect to the ZIS. The ZIS cooperates with the agents to support data exchange between the application servers within the zone. Zone Integration Servers also cooperate with each other to let applications in different zones exchange messages either over a private network or a public network such as the Internet.
At the current time IMS and SIF are working together to investigate the ways in which each organization can utilize the others specifications. SIF is looking at the IMS Question & Test Interoperability and Content Packaging to support K12 assessment/quizzes. IMS is looking at the SIF grade-book. Both organizations are looking on the issues of messaging using SOAP technology.
The Learning Systems Architecture Lab (LSAL) is a research and development center at Carnegie Mellon University. The LSAL research program focuses on the design and creation of Internet based technologies for education and training. The Learning Systems Architecture Lab has developed the concept of a Learning Services Architecture and the Learning Services Stack, as shown in Figure C5, as a framework for developing the next generation of learning technology systems. The Learning Services Stack is based on current approaches used to develop Web Services and service-based systems. It elaborates on the conventional network communications stack. The learning services architecture divides functionality into three major groups or service layers: User Agents, Learning Services and Infrastructure. Each layer presents a well-defined standard communications interface, and functionality is isolated into the distinct layers or service collections. Services within each layer communicate only with services in the same layer and utilize the services provided by the layer directly below.
User Agents are the learning technology systems that provide the human computer interface to access and interact with all learning services and functions; access is only via User Agents. User Agents include systems for content and learning delivery, content and learning management, and authoring and content creation. User Agents are built using the collection of services provided by the Learning Services Layer.
The Learning Services layer includes all services and components that have learning-specific functionality. It is further subdivided into three service sub-layers: Tools, Common Applications and Basic Services. The Tool Layer provides the high-level integrated services used to create a public interface to services for use by the user agents. Tools include those for content delivery, authoring, and learning management, e.g., course delivery, tutors, simulators, quiz and assessment, presentation applications, collaboration, grade and record book, registration, course administration and course management. The Common Applications Layer provides the collection of standard, commonly used services needed by tools and user agents. Common services include: content selection and sequencing, learner profiling, user tracking, learning object management, content management, report generation, and knowledge management. The Basic Services Layer includes core learning services and learning technology-specific versions of commonly used system services such as storage management, workflow, rights management, authentication, validation, logging, etc.
The Infrastructure Layer is the base of the Learning Services Architecture and the service stack. It consists of the services that are independent of the learning domain. It contains the core enabling services such as Transport (SOAP), Discovery (UDDI), Description (WSDL), and Workflow (WSFL). It utilizes core networking services such as HTTP, SMTP, FTP, TCP/IP to create Internet and Web-based learning technology systems.
The Learning Systems Architecture Lab at Carnegie Mellon University is a Contributing member of IMS. The CMU Learning Technology System Architecture has been one of the cornerstone pieces of work that have informed the development of the IAF. The CMU Learning Technology System Architecture is considerable more detail within its layered structure and much of this will be used to inform the detailed development of the IMS specifications within the context of the abstract framework.
The OpenUSS project is designed to support all universities, institutes, faculties and students. The project has two kinds of activity:
The OpenUSS concept is based on the Application Service Provider (ASP) model, which means that one or more organizations (Universities, Schools, Communities, etc.) can be handled within one instance of OpenUSS. OpenUSS gives users the flexibility to use their chosen appliances - the so called multi-channel information delivery - to access the OpenUSS instance e.g., InternetPC, PDAs, and mobile phones.
OpenUSS is based on a component-oriented architecture, which divides the whole components into two parts: Foundation Components and Extension Components. As shown in Figure C6(a), the Foundation Components are the main components within OpenUSS. They represent the eLearning domain-oriented components like Assistant, Student, Enrollment, etc. All the domain neutral functionalities of OpenUSS are implemented as Extension Components. Discussion, Chat, Lecture, etc. represent some of the Extension Components available. The separation of both component types makes it easier to develop more functions separately from the whole system.
From the technology perspective the OpenUSS is built upon a multi-tier architecture and Java2 Enterprise Edition (J2EE), as shown in Figure C6(b). The separation of the Presentation layer, Business Process Layer and Data Layer is the most important part in the OpenUSS technical design. The Presentation layer is implemented with Servlet APIs. The Business Process Layer is designed and implemented with Enterprise JavaBeans (EJB). Any database systems that support Java Database Connection (JDBC) can be used to cover the Data Layer of OpenUSS.
The SUN e-learning framework [SUN, 03] can be broken down into four layers, each with a series of modular components. Beginning with the user, these four tiers are (from top to bottom):
The presentation tier allows end-users to interact with the service or application, and comprises both navigation and presentation logic.
This tier represents the services that everyone needs to do eLearning, or e-commerce. Since they are not role specific, and are not dependent on any particular pedagogic function, they should not be part of the E-Learning Service Tier.
The UK eUniversity's platform is based upon the Sun Microsystems eLearning Framework (as described above). The framework consists of a collection of service definitions separated from implementation. This allows for vendor implementation to be specialized at the service level for 'best of breed' selection and ensuring the architectural integrity is retained while slotting in additional services.
The model also protects investment by wrapping existing implementations into a service. The service wrappers also allow for future proofing by replacing a service implementation with another while retaining the architectural integrity and without disrupting the surrounding services.
The services are completely interoperable and can be implemented as a complete collection or standalone. In applying the framework to an existing environment, services can be implemented optionally to complement existing implementations.
SUN and UKeUniversity are both IMS Contributing Members. IMS and OKI are working with SUN to evaluate the ways in which the SUN eLearning architecture can make use our respective specifications.
UNIVERSAL was a European Union Framework V project that was investigating educational brokerage networks for higher education [Universal, 02]. The idea of building educational brokerage networks is about making learning resources delivered through dispersed delivery systems available via an educational broker. Within the network the broker acts as a central system, providing facilities for managing exchange relationships between learning resources providers and consumers. As an educational mediator the broker combines, both, a collaboration facility for distributed educational activities and a market place for educational materials, in one system.
Users are able to provide learning resources to the broker and specify offers (i.e., usage terms), which consumers of those learning resources are asked to agree on before accessing the resource. Based on learning resource descriptions and usage conditions, learning resources are advertised through a catalogue and/or mailing lists. Users can choose and access learning resources from various kinds of delivery systems (e.g., video conferencing applications, learning management systems, streaming media servers, etc.), but have to agree on the offer terms before getting access to a resource.
Although the broker provides its service via a central web site, the system architecture is based on a network of specialized educational systems. The broker is a super system interacting with various decentralized delivery systems, which hold educational material or provide educational activities. Within the educational brokerage network the brokerage service is centralized, where as the content provision service is de-centralized. A delivery system can be a web server-based learning resource repository, a streaming media server, a video conferencing system or learning management system. The network can provide, both, static learning content (i.e., educational material in broker terms) and educational events with a specific time-table and a virtual meeting place (i.e., educational activities in broker terms).
The architectural framework consists of three layers as shown in Figure C7. The two top layers (Application Layer and Administration Layer) contain a number of services that facilitate the broker to support the exchange process and to administer user and system registration. The Communication Layer defines the middleware that can be used to remotely invoke services.
The application layer provides several application services along the exchange process. It relies on a trusted business environment, where users and systems are authenticated by services provided by the administration layer. There is a Provision service, which replicates learning resource descriptions and offer information between the delivery systems and the broker. Learning Resource Management provides means for uploading an educational material to a delivery system. The Inspection service can be used to check the status (e.g., availability) of learning resources and systems. The Querying service provides an interface for realizing multiple, federated brokers. The Access Control service grants users access control and the Access and Delivery interface supports learning resource access via the broker. The Billing service provides an interface to payment systems.
This work is from a completed EU Framework V project. At the current time there is no IMS interaction with this work.
MOBIlearn is a worldwide European-led research and development project exploring context-sensitive approaches to informal, problem-based and workplace learning by using key advances in mobile technologies. The MOBIlearn project consortium involves 24 partners from Europe, Israel, Switzerland, USA and Australia. Their competencies are integrated and extended by a Special Interest Group that includes 250 of the world's leading IT organizations. The project addresses most of the key objectives of the Multimedia content and tools area of FP5 IST programme and it is strategically positioned to provide relevant research outcomes for the FP6.
For a mobile learning experience, the interoperability of a number of services, even new ones, has to be guaranteed, in the framework of properly defined pedagogical models. One of the major initiatives in this sector is the MOBIlearn project, whose objective is the definition of an abstract model, the development of an application profile and the realization of a Mobile Learning Management prototype. The Mobile Learning Management is a service accessible by eLearning applications (LCMS, LMS) to extend their functionalities to the ubiquitous learning, using:
The main interoperability needs of the Mobile Learning Management service are:
This work is from a EU Framework V project. Giunti Labs are the project coordinators and they are an IMS Contributing Member. At the current time the IMS has a special interest group that is looking into eLearning issues with respect to mobility.
Better public services tailored to the needs of the citizen and business, as envisaged in the UK online strategy, require the seamless flow of information across government [eGIF, 03a], [eGIF, 03b]. The UK's e-Government Interoperability Framework (e-GIF) sets out the UK Government's technical policies and specifications for achieving interoperability and information systems coherence across the public sector. The e-GIF defines the essential pre-requisites for joined-up and web enabled government. It is a cornerstone policy in the overall e-Government strategy.
Adherence to the e-GIF specifications and policies is mandatory. They set the underlying infrastructure, freeing up public sector organizations so that they can concentrate on serving the customer through building value added information and services. It will be for the organizations themselves to consider how their business processes can be changed to be more effective by taking advantage of the opportunities provided by increased interoperability.
The main thrust of the framework is to adopt the Internet and World Wide Web specifications for all government systems. Throughout this section use of the term "system" is taken to include its interfaces. There is a strategic decision to adopt XML and XSL as the core standards for data integration and management of presentational data. This includes the definition and central provision of XML schemas for use throughout the public sector. The e-GIF also adopts specifications that are well supported in the market place. It is a pragmatic strategy that aims to reduce cost and risk for government systems whilst aligning them to the global Internet revolution.
The Framework also sets out policies for establishing and implementing meta-data across the public sector. The e-Government Metadata Standard will help citizens find government information and resources more easily. Stipulating policies and specifications in themselves is not enough. Successful implementation will mean the provision of support, best practice guidance, toolkits and centrally agreed schemas. To provide this, the government has launched the UK GovTalk web site. This is a Cabinet Office led, joint government and industry facility for generating and agreeing XML schemas for use throughout the public sector. Schemas can be found at http://www.govtalk.gov.uk/interoperability/xmlschema.asp. UK GovTalk is also used for wide consultation on a number of other e-Government frameworks and documents.
At the present time the eGIF recommendations have started to address eLearning (Table 10 in [eGIF, 03b]). The eGIF shows that several of the IMS specifications are under review for adoption within eGIF; see Table C1. Later versions of eGIF will further expand on which eLearning specifications are to be formally adopted. Under e-Government there is also a set of recommendations for the usage of XML Schema [eGIF, 02].
| Industry Standard and Sponsoring Organization |
Areas covered by the standards developed by the organization |
eGIF status A = Adopted; see notes for applicability R = Recommended for consideration U = Under review by an ad-hoc group F = For future consideration |
|
|---|---|---|---|
| Status |
e-GIF area of applicability |
||
| IMS Content Packaging (V1.1.2) Information Model Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Content Packaging (V1.1.2) XML Binding Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| SCORM 1.2 Content Aggregation Model application profile Sponsor: ADL http://www.adlnet.org/index.cfm?flashplugin=1&fuseaction=home |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| SCORM 1.2 Runtime API application profile Sponsor: ADL http://www.adlnet.org/index.cfm?flashplugin=1&fuseaction=home |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IEEE 1484.12.1 - 2002 LOM Sponsor: IEEE http://www.ieee.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Meta-data (V1.2.1) XML Binding Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Question and Test Interoperability (V1.2.1) Information Model Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Question and Test Interoperability (V1.2.1) XML Binding Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Enterprise (V1.1) Information Model Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Enterprise (V1.1) XML Binding Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Learner Information Package (V1.0) Information Model Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| IMS Learner Information Package (V1.0) XML Binding Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Reusable Definition of Competency or Educational Objective (V1.0) Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Digital Repositories (V1.0) Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Simple Sequencing (V1.0) Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Learning Design (V1.0) Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
U |
Under review by OeE/DfES e-learning Working Groups |
| IMS Guidelines for Developing Accessible Learning Applications (V1.0) Sponsor: IMS Global Learning Consortium, Inc. http://www.imsglobal.org/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| BS7988 A code of practice for the use of IT in the delivery of assessments Sponsor: BSI http://www.bsi-global.com/ |
e-learning |
R |
Recommended for consideration by OeE/DfES e-learning Working Groups |
| BS8426 A code of practice for e-support in electronic learning systems Sponsor: BSI http://www.bsi-global.com/ |
e-learning |
F |
For future consideration by OeE/DfES e-learning Working Groups |
| BS8419 Interoperability between Metadata Systems used for Learning, Education and Training Sponsor: BSI http://www.bsi-global.com/ |
e-learning |
F |
This is under development and will be considered in the future by OeE/DfES e-learning Working Groups |
IMS staff and several of IMS's UK Contributing Members have been advising the UK's eEnvoy Office on the recommendations for the adoption of eLearning specifications within eGIF.
Within the UK, the Joint Information Systems Committee (JISC) is responsible for undertaking applied research and development into information systems for adoption with the Higher Education, and increasingly the Further Education, communities. In the past few years there have been three eLearning architectural focused projects, namely:
While recognizing that the world at large will continue to use terminology in different and often ambiguous ways, the term Virtual Learning Environment (VLE) is used to refer to the "online" interactions of various kinds which take place between learners and tutors. The JISC MLE Steering Group has said that VLE refers to the components in which learners and tutors participate in "online" interactions of various kinds, including online learning. The JISC MLE Steering Group has said that the term Managed Learning Environment (MLE) is used to include the whole range of information systems and processes of a college (including its VLE if it has one) that contribute directly, or indirectly, to learning and the management of that learning.
The principle functions that the complete VLE needs to deliver are:
As shown in the Figure C10, the VLE will act as a 'portal' to online Curriculum Mapping, Assessment, Communication, Delivery, Tutor support and Tracking facilities. The VLE makes up only one part of the college's overall systems (both computerized and non-computerized). Interfacing between these systems is possible by 'connecting up' the constituent parts by the use of interoperability standards such as IMS (plus required extensions). Examples of these are between the Student Record Systems and the VLE and between Learning resources (or content) and the VLE.
JISC recently completed a series of pilot projects that investigated interoperability between various eLearning system components as used with the UK Further Education college system. The framework shown in Figure C9 is the result of investigating the ways in which some interoperability specifications can be used to support intra- and inter- College data exchange.
The DELIVER project (this is scheduled for completion in July 2003) will design and implement practical software tools for end-users and administrators of institutional VLEs and Library Management Systems to facilitate the consistent creation and easier use of course-based resource lists.
The overall aim of the project is to create a series of library tools that will allow access to a range of library systems and services on a course-specific basis from within a VLE. This software tools will encompass generic library tools, subject-specific tools and course-specific, directed learning tools.
The specific objectives are to:
With an increasing number of courses available online and the proliferation of networked information resources there is a pressing need to provide integrated access for students and to integrate support and management from academics and librarians. The JISC has funded the development of an Authenticated Networked Guided Environment for Learning (ANGEL) to provide powerful access management tools. ANGEL will be able to offer students:
Educators and librarians will be able to:
ANGEL built on research in integrating access in the hybrid library, such as the Headline PIE, and in VLEs, such as the De Montefort University's Learning Domain. The Networked Authentication part of the effort developed an access management system. ANGEL also worked closely with those responsible within the JISC for authentication and security of information. As well as portable, reusable, open software components for use by Further and Higher Education, the project delivered updates on personalization, authentication and authorization developments and public reports on meta-data, licensing and other interoperability issues.
JISC is an IMS Contributing Member with the Centre for ELearning Technology and Information Systems (CETIS) acting on their behalf13. The IMS receives extensive input from CETIS on JISC activities and the CETIS technical team play a significant role in the development of the IMS specifications. IMS has received many core use cases from the UK Higher Education and Further Education domain, particularly regarding the IMS Enterprise, Content Packaging and LIP specifications. CETIS runs many special interest groups aligned with the IMS specification activities.
Electronic Business Extensible Markup Language (ebXML) is an international initiative established by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) with a mandate to undertake a 15-18 month program of work. As identified in the ebXML Terms of Reference, the purpose of the ebXML initiative is to research and identify the technical basis upon which the global implementation of XML can be standardized. The goal is to provide an XML-based open technical framework to enable XML to be utilized in a consistent and uniform manner for the exchange of electronic business (eb) data in application to application, application to human, and human to application environments-thus creating a single global electronic market. 14
ebXML is based on international standards and is itself intended to become an international standard [ebXML. 01a], [ebXML, 01b], [ebXML, 01c], [ebXML, 01d], [ebXML, 01e], [ebXML, 01f], [ebXML, 01g]. A key aspect for the success of the ebXML initiative is adherence to the use of the W3C suite of XML and related Web technical specifications to the maximum extent practical. Although these specifications may not provide the optimal technical solution, acceptance of ebXML by the business community and technical community is tied to XML. However, certain key elements of the ebXML technical framework may require adopting alternative technologies and technical specifications-such as those of the Internet Engineering Task Force (IETF), International Organization for Standardization (ISO), Institute of Electrical and Electronics Engineers (IEEE), International Electrotechnical Commission (IEC), UN/CEFACT, OASIS, and the Object Management Group (OMG).
The major ebXML technical specifications consist of the:
At the current time there is no formal relationship between IMS and ebXML. The IMS specification development activity is evaluating the ways in which ebXML could be used to support eLearning.
| Title |
The IMS Abstract Framework: White Paper |
| Authors |
Colin Smythe (IMS) |
| Version |
1.0 |
| Version Date |
01 July 2003 |
| Status |
Final |
| Summary |
During the past 30
months the IMS has released a unique set of interoperability
specifications within the eLearning technology community. The IMS
Abstract Framework (IAF) is a device to enable the IMS to describe the
context within which it will continue to develop its eLearning
technology specifications. This framework is not an attempt to define
the IMS architecture, rather it is mechanism to define the set of
interfaces for which IMS may or may not produce a set of
interoperability specifications. In the cases where IMS does not
produce a specification then every effort will be made to adopt or
recommend a suitable specification from another organization. It is the
intention of IMS that this Abstract Framework and the associated IMS
specifications produced to realize the exchange of information between
the identified services will be adopted in a manner suitable for a
particular system requirement. |
| Revision Information |
01 July 2003 |
| Purpose |
The first formal
distribution of the IMS Abstract Framework. This document has been
distributed to the IMS Technical Board, the IMS Contributing Members,
the IMS Developers Network and organizations that participated in its
development. |
| Document Location |
http://www.imsglobal.org/af/index.cfm |
The individuals who contributed to the development of this white paper are:
| Version No. | Release Date | Comments |
|---|---|---|
| Final 1.0 |
01 July 2003 |
The first formal distribution of the IMS Abstract Framework. This document has been distributed to the IMS Technical Board, the IMS Contributing Members, the IMS Developer network and organizations that participated in its development.
Feedback on the material presented in this document is welcomed.
Please send all comments, questions to: [email protected]. |
A
Abstraction 1, 2
Access 1, 2, 3
Access Control 1
Accessibility 1, 2, 3
AICC
AICC 1, 2, 3, 4, 5
Aviation Industry CBT Committee 1
CMI 1, 2, 3, 4
Computer Managed Instruction 1
American Sign Language 1
API 1, 2, 3, 4, 5, 6
Application 1, 2, 3, 4, 5, 6, 7, 8, 9
Application Layer 1
Application Service 1, 2, 3, 4, 5, 6, 7, 8
Application Services
Assessment 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Calendar 1
Collaboration 1, 2, 3, 4
Content Management 1
Enterprise Service 1, 2
Architecture 1, 2, 3, 4, 5, 6, 7, 8
Assessment 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Assets 1
Assistive Technology 1
Authentication 1, 2, 3
Authorization 1, 2
Aviation Industry CBT Committee 1
C
CEN/ISSS 1
Certification 1
Class 1, 2, 3
Class Diagram 1
CMI 1, 2, 3, 4
Common Service 1, 2, 3, 4, 5, 6, 7, 8, 9
Common Services
Authentication 1, 2, 3
Authorization 1, 2
Discovery 1, 2
Identification 1, 2, 3, 4, 5
Querying 1
Registry 1, 2
Scheduling 1
User Messaging 1
Workflow 1, 2
Component 1, 2, 3
Component Diagram 1
Components 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Computer Managed Instruction 1
Conformance 1, 2, 3, 4, 5
Conformance Profile 1, 2
Content Aggregation 1, 2, 3, 4
Content Package 1
Content Package Specification 1
CSS 1
Curriculum 1
D
DC 1
DCMI 1
Deployment Diagram 1
Digital Repository 1, 2
Directory 1
Document Type Definition 1
Domain Profile 1, 2, 3
DTD 1
Dublin Core
DC 1
DCMI 1
Dublin Core 1, 2, 3
E
ebXML
ebXML 1, 2, 3, 4, 5, 6
Electronic Business XML 1
TR&P 1
Transaction, Routing & Packaging 1, 2, 3
eGIF 1, 2, 3, 4
Electronic Business XML 1
Enterprise Specification 1
Environment 1, 2, 3, 4, 5, 6, 7, 8
F
File Transfer Protocol 1, 2
Framework 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
FTP 1, 2, 3, 4, 5
G
Generic Transport Sub-layer 1
H
Higher Education Knowledge and Technology Exchange 1
HR-XML 1
Hypertext Transfer Protocol 1, 2, 3
I
IEEE
Abstraction 1, 2
Access Control 1
API 1, 2, 3, 4, 5, 6
Authentication 1, 2, 3
Authorization 1, 2
Binding 1, 2, 3
Curriculum 1
IEEE 1, 2, 3, 4, 5, 6, 7
LOM 1, 2, 3, 4
LTSA 1, 2, 3, 4
LTSC 1, 2, 3
PAPI 1
IEEE LTSA 1, 2, 3, 4
IEEE LTSC 1, 2, 3
IETF
File Transfer Protocol 1, 2
FTP 1, 2, 3, 4, 5
Hypertext Transfer Protocol 1, 2, 3
IETF 1, 2
Internet Engineering Task Force 1, 2
Internet Protocol 1, 2
IP 1, 2, 3, 4
LDAP 1
Lightweight Directory Access Protocol 1
Simple Mail Transfer Protocol 1, 2
SMTP 1, 2, 3, 4, 5
TCP 1, 2, 3, 4
Transmission Control Protocol 1, 2, 3
Implementation 1, 2, 3, 4, 5, 6, 7
IMS Abstract Framework 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Infrastructure 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
Infrastructure Layer 1, 2, 3, 4, 5
Initiator 1
Interface 1, 2, 3, 4, 5
Internet Engineering Task Force 1, 2
Internet Protocol 1, 2
IP 1, 2, 3, 4
J
JISC
Managed Learning Environment 1, 2
MLE 1, 2, 3
Virtual Learning Environment 1, 2
VLE 1, 2, 3, 4
K
Knowledge Management 1
L
Layers
Applications 1
Infrastructure 1, 2, 3, 4, 5
LCMS 1, 2, 3, 4
LDAP 1
Learner 1, 2, 3, 4, 5, 6, 7, 8, 9
Learner Information Package 1, 2, 3, 4, 5
Learning Activity 1, 2, 3
Learning Content Management System 1
Learning Design 1, 2, 3, 4, 5
Learning Management 1, 2, 3
Learning Management System 1
Learning Object 1, 2, 3
Lightweight Directory Access Protocol 1
LOM 1, 2, 3, 4
M
Managed Learning Environment 1, 2
Meta-data 1, 2, 3, 4, 5, 6, 7, 8, 9
Meta-data Specification 1, 2
Method 1
MLE 1, 2, 3
O
Object 1, 2, 3, 4, 5
OKI
Application Service 1, 2, 3, 4, 5, 6, 7, 8
Common Service 1, 2, 3, 4, 5, 6, 7, 8, 9
OKI 1, 2, 3, 4, 5, 6, 7
Open Knowledge Initiative 1, 2
Open Knowledge Initiative 1, 2
OpenUSS 1, 2, 3
Organization 1, 2
Outcomes Processing 1
P
Package 1, 2, 3
Package Diagram 1
PAPI 1
Privacy 1
Q
QTILite Specification 1
Query 1, 2, 3
R
Reference Model 1
Registry 1, 2
Repository 1, 2
Request 1, 2, 3
Resource 1, 2, 3, 4, 5, 6, 7
Respondent 1
S
Scalable Vector Graphics 1
Schools Interoperability Framework 1, 2, 3, 4
SCO 1, 2
SCORM
SCO 1, 2
SCORM 1, 2, 3, 4, 5, 6, 7, 8, 9
Sharable Content Object 1, 2, 3
Sharable Content Object Reference Model 1, 2
Search 1, 2
Section 1
Sequence Diagram 1
Service 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Service Access Point 1, 2, 3, 4, 5
Services
Application
Assessment 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Calendar 1
Content Management 1
Enterprise Service 1, 2
Common
Querying 1
Scheduling 1
User Messaging 1
Workflow 1, 2
Sharable Content Object 1, 2, 3
Sharable Content Object Reference Model 1, 2
SIF
Schools Interoperability Framework 1, 2, 3, 4
SIF 1, 2, 3, 4, 5, 6, 7, 8, 9
ZIS 1, 2, 3
Zone Integration Server 1, 2, 3, 4
Simple Mail Transfer Protocol 1, 2
Simple Object Access Protocol 1, 2
Simple Sequencing 1, 2, 3, 4, 5, 6, 7, 8
Simple Sequencing Specification 1
SMIL 1
SMTP 1, 2, 3, 4, 5
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9
SOAP with Attachments 1, 2, 3, 4, 5
Student Administration System 1
Student Information System 1
Synchronized Multimedia Integration Language 1
T
TCP 1, 2, 3, 4
Text Telephone 1
TR&P 1
Tracking 1
Transaction, Routing & Packaging 1, 2, 3
Transmission Control Protocol 1, 2, 3
U
UML
Class 1, 2, 3
Class Diagram 1
Component 1, 2, 3
Component Diagram 1
Deployment Diagram 1
Object 1, 2, 3, 4, 5
Package 1, 2, 3
Package Diagram 1
Sequence Diagram 1
Use-case 1, 2, 3
Use-case 1, 2, 3
Use-case Portfolio 1, 2, 3
User 1, 2, 3, 4, 5, 6, 7, 8, 9
User Interface 1, 2
V
Virtual Learning Environment 1, 2
VLE 1, 2, 3, 4
W
W3C
Document Type Definition 1
DTD 1
Simple Object Access Protocol 1, 2
SOAP with Attachments 1, 2, 3, 4, 5
Synchronized Multimedia Integration Language 1
W3C 1, 2, 3, 4, 5
WAI 1
Web Accessibility Initiative 1
Web Services Description Language 1, 2, 3, 4
World Wide Web Consortium 1
WSDL 1, 2, 3, 4, 5, 6, 7, 8
XML 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
XML Schema Definition 1, 2
XSD 1, 2, 3, 4
WAI 1
Web Accessibility Initiative 1
Web Services Description Language 1, 2, 3, 4
World Wide Web Consortium 1
WSDL 1, 2, 3, 4, 5, 6, 7, 8
X
XML 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
XML Binding 1, 2, 3, 4, 5
XML Protocol 1, 2
XML Schema Definition 1, 2
XMLP 1
XSD 1, 2, 3, 4
Z
ZIS 1, 2, 3
Zone Integration Server 1, 2, 3, 4
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Abstract Framework: White Paper ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Abstract Framework: White Paper Revision: 01 July 2003