Educom's IMS Design Requirements
December 19, 1997

ii
Table of Contents

1.      OVERVIEW        

1.1     Statement of Need       
1.2     IMS Project Goals and Objectives        
1.3     Stakeholders    
1.4     Special Terms   
1.5     Organizational/Policy Issues    
1.5.1   Project Deliverables    
1.5.2   Scope of Specification  
1.5.3   Future developments and potential roles of IMS  
1.5.4   Value propositions/market forces        
1.5.5   Relationship to prior work      
1.5.6   Specification vs. Standards     
1.5.7   Compliance and Certification of Compliance      

2.      Design  

2.1     Design Context  
2.2     design methods  
2.3     design structure        
3.      Requirements    

3.1     Group management        
3.1.1   Essential Requirements  
3.1.2   Secondary Requirements  
3.1.3   Don't Preclude  

3.2     personal profile management     
3.2.1   Essential Requirements  
3.2.2   Secondary Requirements  

3.3     activity management     
3.3.1   Essential Requirements  
3.3.2   Secondary Requirements  

3.4     assessment and certification management 
3.4.1   Essential Requirements  
3.4.2   Secondary Requirements  
3.4.3   Don't Preclude  

3.5     content management      
3.5.1   Essential Requirements  
3.5.2   Secondary Requirements  

3.6     Commerce and licensing management       
3.6.1   Essential Requirements  
3.6.2   Secondary Requirements  
3.6.3   Don't Preclude  

3.7     security management     
3.7.1   Essential Requirements: 
3.7.2   Secondary Requirements  

3.8     technical Administration management     
3.8.1   Essential Requirements: 
3.8.2   Secondary Requirements  

3.9     summary of requirements 
4.      Implementation and Design Rationale     

4.1     recommended requirements        
4.1.1   GROUP MANAGEMENT        
4.1.2   PERSONAL PROFILE MANAGEMENT     
4.1.3   ACTIVITY MANAGEMENT     
4.1.4   ASSESSMENT AND CERTIFICATION MANAGEMENT 
4.1.5   CONTENT MANAGEMENT      
4.1.6   COMMERCE AND LICENSING MANAGEMENT       
4.1.7   SECURITY MANAGEMENT     
4.1.8   TECHNICAL ADMINISTRATION MANAGEMENT     

4.2     issues and approaches   
4.2.1   Metadata        
4.2.2   User Profile    
4.2.3   Content 
4.2.4   Management      
4.2.5   External        



2

iii

IMS Project Requirements

Preface

This public document is derived from the EDUCOM/NLII Instructional Management Systems (IMS) design requirements process and presents the operational, business and functional requirements for development of the IMS specification. This specification will be published and implemented in a proof of concept prototype that demonstrates the operation of an IMS-compliant system. Both the specification and the prototype will be made freely available early in 1998.
The IMS specification and prototype are being developed by an EDUCOM-sponsored partnership consisting of academic, commercial and government organizations.  A group of representatives from the partnership (reflecting the perspectives of all the different IMS stakeholders) created the original version of this document in March 1997. While the primary audience for this document is a technical one, it is also intended to serve as a means for communicating the scope and functionality of the IMS to other individuals such as educators, learners, and the business community.


This information is confidential and proprietary to the EDUCOM IMS Partnership and may not be disclosed without permission.

iv

Organization of this Document

The document has four major sections:  
1. Overview:
presents a brief rationale for an industry-standard specification, describes the IMS project, identifies the stakeholders, introduces some special terms used in describing the requirements, and identifies organizational and policy issues associated with the project.  The project deliverables are enumerated as 1) a technical specification that outlines how learning materials and environments should be developed for operating and managing compatible content and courses, and 2) a prototype that serves as a proof-of-concept implementation of the specification.

2. Design: defines the overall design context and parameters for the IMS technical specification, and describes the design methods for collecting user requirements.

3. Requirements: the core of the document is a comprehensive list of the functional requirements that will serve as the basis for the IMS specification.  The requirements are organized by features and prioritized according to the centrality of any given requirement to the specification.

4. Implementation and Design Rationale: discusses how the IMS requirements will be translated into the technical specification and proof-of-concept prototype.  In addition, this section discusses implementation issues and design rationale for addressing the issues of implementing the requirements.


4


1. OVERVIEW


The IMS project is a partnership of educational organizations and companies working under the auspices of the EDUCOM National Learning Infrastructure Initiative to make it easier for children, students, employees, and adults to learn via the Internet.
Development of software tools for teaching and learning and their integration into the learning environment have historically been hampered by the lack of a commonly accepted specification that would permit them to be readily shared among institutions and across a wide range of technical environments. Given the rapid transition in the information technology environment from a PC-based model to a network-based model, coupled with a shift in pedagogy from teacher-centered to learner-centered paradigms, the development of a non-proprietary industry-standard specification can overcome this limitation and improve the effectiveness of technology as means of enhancing learning.


1.1 Statement of Need


Several obstacles have been identified that may impede the provision of effective online learning materials and learning environments.  The IMS Project will provide for the following needs:
Standard methods for describing and locating online environments and materials
Integrative strategies for activities of teaching, learning, coordinating, and providing educational content and experiences
Support for interactive platform-independent materials
Incentives and structure for developing and sharing content across contexts

1.2 IMS Project Goals and Objectives


In order to address the above needs, the IMS project will seek to support the NLII's goals of  improving access, containing costs and enhancing the quality of educational opportunities.  To this end, the goal of the IMS project is to enable an open architecture for online learning.

An open architecture will provide for the following objectives:
Center the educational experience around the needs and interests of the learner.
Enable learning to occur any time, any place.
Allow for greater customizability and flexibility of the learning environment.
Promote interactions among teachers and learners.
Protect and compensate the work of educational content developers.
Improve the quality and number of choices in on-line learning content and services
In order to create an open architecture for online learning, the development of the IMS specification began by defining a range of interchanges, or interactions, between education-oriented parties such as learners, teachers, and education providers and collections of learning materials.
Interchanges within and between learning environments will use Internet protocols across the public Internet, through private Intranets, or within self-contained implementations. The IMS specification will define the interface between systems and components, and describe the information that may be exchanged through these interfaces. As an open architecture, however, it will not prescribe the operations of specific components, nor will it prescribe a particular  user interface or instructional methodology. Systems and content that abide by the IMS specification will be considered IMS-compliant systems and content.


1.3 Stakeholders


There are several stakeholders who will be affected by the IMS project.  We have identified these stakeholders in terms of the different roles involved in the process of learning: learners, teachers, coordinators, and providers.  These roles are not discrete and people will often assume the activities of multiple roles.  For example, a teacher may also be a learner and a content provider.  A service provider may also play the role of an academic coordinator and vice-versa.  

The IMS project has identified some of the characteristics of and benefits for its different constituencies:
Learners
- will be able to own and customize the learning process to a degree heretofore not possible.  They will be able to learn anytime, anyplace.  Learners may be children, students, teachers, workers, or adults.  They may have a range or mix of motivations for learning, such as education, employment, or enjoyment.
Teachers
- will be able to access and customize easily a wide range of instructional materials.   They will be able to interact with learners - anytime, anyplace - and will have extraordinary flexibility.  Teachers may be formal instructors and trainers or informal mentors and guides.
Providers
- will be able to publish to standards that will assure them of a large market for their products and thus promote the development and distribution of instructional software.  Content providers may be large publishing houses or single authors.  They will both have the ability to gain broad dissemination of their work and will be assured that it will interoperate with other objects on a basic level.  
Coordinators
- will be able to offer innovative programs and learning opportunities in both traditional and non-traditional environments.  Coordinator include educational institutions, commercial education providers, technology companies, etc.

While these stakeholders are described in traditional terms that reflect today's organizational structures and functions, availability of IMS implementations will facilitate the development of non-traditional roles and structures, thus creating a potential for the development of new groups of stakeholders.


1.4 Special Terms


A brief overview of the special terms used in this document is provided here.
An IMS container is a collection of one or more learning materials.  The learning materials can be non-interactive information, such as a Web page with text and images, interactive content which responds in different ways based on input from a learner, or tools for collaboration with other learners.  Containers include a Container ID, a unique identifier, and metadata, information that describes the container and its contents.   
Containers can be aggregated, or nested, by placing one or more containers inside another container, like building a course from a collection of selected readings, self-tests, etc.  A container can be disaggregated by removing it from a larger container which encompasses it. An IMS container which is self-sufficient for teaching and learning is called a learning offering.
Containers are packaged before they are distributed.  Packaging might include filling out information, such as copyright attribution and licensing restrictions, if any.
Offerings, or any IMS container in general, operate in an IMS environment, which is an implementation of the IMS Specification.  An IMS environment "unwraps" the IMS container and extract its contents for delivery to the learner and facilitates interactions within the learning environment.


1.5 Organizational/Policy Issues


This section identifies assumptions, requirements and policy issues that relate to the management of the IMS project, rather than to the design or content of the IMS specification.


1.5.1 Project Deliverables


The benefits of the IMS will be realized through the creation of a technical specification document that outlines how learning materials and environments should be developed for operating and managing compatible content and courses. The first iteration of the technical specification will be openly available to developers in March of 1998.  

In order to demonstrate the functionality of the technical specification, IMS prototype components and base environment will be created as a type of reference implementation.  The prototype will serve as a proof of concept for the community of potential IMS users and developers. Any code developed for the prototype will also be made freely available.
The prototype is only one implementation of the specification; the intention of the IMS Project is to enable numerous IMS implementations.

The IMS project is focused on practical outcomes:  the enhancement of learning, broader dissemination of best practices,  and market development for technology-mediated learning. It is not a research project, though the development of enhanced on-line learning environments may offer opportunities for research into technology-mediated learning methods and outcomes.

Therefore, the primary deliverables of the IMS project are:
Technical Specification
Proof-of-concept Prototype

1.5.2 Scope of Specification


The IMS Specification includes requirements for some of the activities within an online learning environment.   These requirements prescribe specific behavior and boundaries of IMS-compliant environments.
For other activities, the IMS Specification does not include prescriptive requirements because doing so would be either unrealistic or would stifle innovation in the development of IMS-compliant environments and content.  These activities play a necessary role in online learning environments.  Therefore, the IMS Specification includes ways in which these activities can be interfaced into an IMS environment.  The IMS Specification provides an interface to but does not prescribe how to:
Establish costs of educational materials
- Most organizations have their own business rules that determine the cost of their offerings.  In many cases, these business rules and associated databases represent a large investment in their creation and the cost of the computer systems in which they reside.  The IMS provides interfaces into these systems to leverage the investment they represent.
Develop or select a pedagogical or assessment methodology -
The IMS provides interfaces to exchange certain types of information with instructional and assessment content.  The IMS does not prescribe how teaching and assessment should take place. The IMS specification is thus pedagogy-neutral, in that it enables a range of learning scenarios, including synchronous/asynchronous, local/distant, push/pull/hybrid, constructivist/behaviorist, etc., in any combination. IMS-compliant learning environments can support both traditional learning models, and enable the development of entirely new ones.
Store and retrieve information --
- There are many ways in which information is written to and read from computer storage systems.  Each organization may have different requirements and existing information storage/retrieval solutions.  The IMS Specification does not include requirements for storing and retrieving data within storage systems, such as relational databases, but the IMS Specification does include requirements about how it will send and receive information from these storage systems. It is assumed that each implementation of an IMS environment will provide the associated mechanism for storing/retrieving information to support the IMS environment's need to send or receive information.   The IMS specification and an implementation of an IMS environment is analogous to the relationship between a college student and the registrar with respect to transcript information.  There is a defined way for the student to request a copy of his or her transcript.  How the registrar stores and retrieves the information that constitutes the transcript is generally of no concern to the student.
Enroll and admit learners
- Every organization has its own processes and criteria for enrolling and admitting learners.  The processes may be supported by administrative computer systems that represent large investments.  The IMS provides an interface for organizations to leverage their existing processes and computing infrastructure.
User Interface
- The IMS Specification will not include user interface requirements.   User interface requirements could include such things as prescribing what buttons or menu items must appear on a screen, where they should be located, what color highlighted text should be, how to display lists of items, how to display help information, etc.  Prescribing such features would stifle innovation and reduce the ability of IMS-compliant software developers to differentiate their software from each others' products.  The IMS prototype will pull from "best practices" in visual design and therefore encourage common practices by example, but not required in the specification.

The diagram below depicts the boundaries of the IMS Environment.  The IMS Specification will prescribe how interchanges occur both within the IMS Environment and between the borders of the IMS Environment and specific implementations.  The shaded area in the diagram represents the focus of the IMS Specification.  Areas that are outside of the IMS Environment and its gateways, or beyond the fence, are not bound by the IMS Specification.  For example, existing authoring and groupware tools can be implemented in a variety of ways, the only commonality being the ability to bring information to the IMS fence.

FIGURE 1: BOUNDARIES OF THE IMS ENVIRONMENT
The IMS specification is intended to be extremely generalizable, and to be permissive rather than restrictive. The objective of the specification is to facilitate the interchange and management of learning materials, not to force all learning to comply with a particular organizational, or pedagogical model, or with any particular visual interface.

1.5.3 Future developments and potential roles of IMS


anno0
The initial mission of  the EDUCOM-sponsored IMS partnership is to develop and disseminate the IMS prototype and specifications. In the long term, a scaled-down organization will need to continue to exist, with one or more of the following potential roles:
1. Continue to evolve specifications and facilitate the development of freely available code.
2. Mediate the convergence of market implementations of the IMS that have diverged from the existing standards. This function is analogous to the current role of W3C in reconciling market enhancements to HTML and releasing periodic new versions of the HTML standard.
3. Maintain a registry of authorized IMS ID issuers, as a means of ensuring global uniqueness of IMS IDs.
4. Promote the establishment of a means for certifying learning offerings and environments as IMS-compliant.

Initial oversight of the IMS partnership is provided by EDUCOM. Long-term options for oversight of the project include continued EDUCOM sponsorship or becoming a working group under the auspices of  the W3C.


1.5.4 Value propositions/market forces


The IMS partnership will seek to maximize the benefit-cost ratio of the entire IMS-based business/learning model, recognizing the interdependent relationship of goals such as enhancing learning, reducing costs and enhancing revenue. The business model for the IMS partnership will be value-based: the objective being to increase the relative value for all stakeholders.
From an educational consumer perspective, the primary market driver is the potential of IMS-based learning to increase the quality of education, improve access, and reduce costs.
Commercial organizations can gain market advantage from:
Visual interfaces:
development of visual interfaces is an area where businesses and other organizations will add value, innovate, and compete (in the same way as there are currently many different Internet email interfaces to the standard email protocols).
Custom functionality:
the IMS specification is intentionally permissive rather than restrictive, and offers many opportunities for local additions to the core functionality. Such additions can be used by IMS-compliant vendors to develop competitive advantage for their products, and to ensure that IMS does not create a lowest common denominator for products that utilize the specification.
Market growth:
the current supply of on-line learning resources is inadequate. The development of IMS-compliant systems should cause the supply to grow, thus creating a larger market for such products and increasing total revenues for developers and suppliers.

The IMS partnership will rely on market forces to determine a range of issues:
Quality of offerings:
the IMS specification does not impose any qualitative restrictions on content. The market will ensure that appropriate mechanisms develop to permit learners and teachers to identify high quality content. As with any other product in the free market, the advice of caveat emptor applies to consumers of IMS-based educational offerings.
Granularity of offerings:
the IMS specification imposes no limits on the size of an offering, but it is likely that, given the ability to easily aggregate learning materials, the market will encourage content providers to break apart their current instructional offerings into smaller modules.
Certification structures:
while the IMS specification will reflect current models of certification for performance or achievement, it will also permit the development of new educational certification models and structures that will arise in response to market demand.


1.5.5 Relationship to prior work


Online Teaching and Learning Projects
:  The experiences of Miami Dade Community College in developing Project SYNERGY Integrator and the results of a comprehensive analysis of other learning systems will inform the IMS design. In addition, the IMS team is aware of and exploring the many existing web-based teaching and learning management systems.  While the IMS design will not be based on any particular learning system, this analysis will help the design group to ensure that no critical features are overlooked.
Indexing/searching Strategies
:  The IMS partnership will solicit guidance on data dictionary terms from partners and other respected parties that will be utilized to establish indexing standards. These standards are intended to make searching more productive than it would be in their absence.  The IMS design will reflect search strategies and mechanisms developed by library scientists, creators of web search engines, and multimedia authors.

Existing Standards and Protocols:  A core mantra for the IMS Project is to not build what already exists, and to leverage what already works.  As much as possible we will draw from ongoing advances and solutions developed by industry players dedicated to overcoming obstacles for networked learning environments. Where applicable, formal standards and protocols will be incorporated in the IMS design.

1.5.6 Specification vs. Standards


The IMS partnership is creating a specification that is intended to become de facto industry standards that will be distributed and implemented without first going through a formal standards process. At a later time, the IMS project will partner with another organization that will take those industry standards and guide them through the national/international standards process. The rationale for this approach is based on a realization that time to market is extremely important in this environment, and that de facto standards represent a much faster means of disseminating a design into the marketplace than do formal standards.


1.5.7 Compliance and Certification of Compliance


IMS compliance is determined relative to the IMS Specification.  IMS compliance for content is defined as the complete implementation of required IMS metadata and IMS communications protocols.  Certification of content implies no value-judgment as to its quality or appropriateness; only that it meets the technical requirements for use within an IMS-compliant environment..
IMS compliance for learning environments is defined as the ability to recognize and enable IMS communication between IMS-compliant content, between content offerings and the IMS environment, between environments from different vendors, and between users and the environment. Communication, in this instance, implies a recognition and appropriate processing of metadata, and compliance with the IMS Specification with regard to transaction protocols and required operational functions.
IMS content and IMS learning environments may be certified as being compliant with the IMS Specification. Certification may include the right to use a service mark-registered logo on and in the certified product or content. The IMS Project will promote the creation of an entity or entities that provide IMS certification services.
A collection of IMS content may not be designated as IMS certified or compliant if it is shipped with a learning environment product that will not communicate with other IMS environments.

anno01 Self-evident

2


2. Design


Overview

This section will describe the design context into which the IMS Specification and Prototype will be introduced.  Several paradigm shifts are underway in the field of education, the software industry, and the marketplace that are converging to create an environment suited for the IMS Specification.  In addition, this section will relate the methods used for determining what the basic user requirements are for integrating instructional management systems into the current educational context.  Finally, we will outline some of the general technical architecture for implementing the Specification according to the user requirements collected.


2.1 Design Context


One of the most prominent  attributes noted regarding the design context is the changing nature of the landscape, indicating that a paradigm shift is well underway for the process of learning. The shift does not imply a linear movement away from one approach to another.  Rather, the shift is more of an expansion suggesting that the landscape is becoming richer and more diversified as it encompasses multiple approaches.  The following diagram depicts the expanding learning landscape:

FIGURE 2: THE LEARNING LANDSCAPE

At the center of the diagram above are learners, supported by the other IMS stakeholders we've identified:  teachers, providers, and coordinators.  The model above is intended to portray the learning landscape as becoming more learner-centered.  Although some may argue that learning is implicitly learner-centered, the pervasive methods for promoting learning have not always been in the learner's control.  With a richer and more diversified learning landscape developing, the learner has more opportunities to structure his or her own personal experience.
The actual relationship between learners, teachers, providers, and coordinators, however, is not represented well by a flat diagram of concentric circles.  Rather, these parties all relate to one another through a series of interchanges, in the form of communication or interaction, represented more accurately by the tetrahedron model below.

FIGURE 3:  TETRAHEDRON OF LEARNING INTERCHANGES
The black lines represent interchanges and depict two types of communication: between different stakeholders and within each stakeholder group itself.  For example, there are peer to peer interactions among learners, as well as interactions between learners and teachers, providers, and/or coordinators.  What passes between parties involved in an interchange is information, whether in the form of dialogue, a textbook, or a computer program.
The interchanges referenced above are affected by dimensions of the surrounding learning environment.  There are four main dimensions: time, location, affiliation and delivery methods, as indicated in the diagram below.

FIGURE 4:  DIMENSIONS OF LEARNING INTERCHANGES
As for time, the learning environment is not limited to a linear progression and will most likely include both synchronous and asynchronous interactions.  Regarding distance, the environment may be confined to one physical location, or distributed across physical and electronic spaces. Finally, in terms of delivery methods, many learning environments employ multiple channels and methods for delivering information and supporting communication.  The combination of these dimensions constitutes the context of the learning environment.  
An understanding of the learning process and environment as a system of interchanges suggests a model of interrelated parts.  The idea that parts of the learning process and learning materials may be modularized supports the shift to a more diversified and learner driven environment.  One  example of this, is the popularity of the course packet with specifically selected readings or exercises, over the static and standardized text book.  This translates easily to a web environment where teachers or learners are free to pick content from the myriad of sources available.  Another example of modularization in the learning process is the ability to offer a certification test at the beginning of a course that either passes the student or creates an individualized set of materials and exercises to reach certification.
This view of learning as a system of interrelated parts is mirrored by shifts in current models of technology and business that will support the growth of a distributed learning industry.  On the technology side, both hardware and software systems are designed in a manner supportive of modular systems.  Workstations are no longer the primary platform for computer-based learning, rather it is the network of multiple learning stations that constitutes the learning environment.  Similarly, the current interest in object-oriented design lends itself to supporting modular models of learning.
On the business side, companies are recognizing learning environments as dynamic systems with diverse needs rather than one-size-fits-all.  The ability to easily customize materials and environments is supported by a system of interconnected parts.  In addition, business models are exploring how to support the aggregation of content and the reuse of content, rather than inflexible models of all-or-nothing final sales.  The diagram below hightlights the benefits of a model where content can be reused to add more value:

printed textbook model          digital information model

source:  Bob Carlton, ITP

FIGURE 5: COMPARISON OF INFORMATION  BUSINESS MODELS
Whether viewed from a technical, educational, or business model, the field of distributed learning can be seen as the integration of several complimentary parts.  The emphasis on the ability to modularize content or processes should not detract from the seamless interaction of these different modules as the diagram below suggests.

source:  Bob Carlton, ITP

FIGURE 6: INTEGRATIVE VIEW OF DISTRIBUTED LEARNING
Although the paradigm shifts for different aspects of the learning environments are underway, there is often a tension between internal resistance to change and external pressure for institution wide changes.  This resistance will decrease as more stakeholders realize that the new paradigms for teaching will complement but not replace traditional forms of education.  Overall, however, whether or not change is welcomed, learners are becoming more demanding consumers of instructional offerings. The need for change is being driven by learners and the impetus is to create and support truly learner-centered environments.


2.2 design methods


As a result of the paradigm shifts described above, the lines between the teacher, learner, provider and coordinator are blurring.  Teachers, for example, are engaging in activities traditionally associated with professional content providers such as publishers.  Many teachers are assembling their own work and the work of others into customized course packets for distribution.  Similarly, content providers are engaging in teaching activities by offering courses outside of traditional educational affiliations.  Learners are assuming the roles of both providers and teachers, taking a more active approach to shaping their learning experiences.  The coordinator of a learning environment establishes and maintains the relationships between teachers, learners, and providers; however, a formal relationship with one institution or organization is no longer required.
Relationships between providers, teachers, learners, and coordinators still exist, but they have changed and continue to change significantly.  Because of these changes, the IMS Project focused on the activities of the learning process rather than on the fluctuating roles of individual parties.  Rather than solicit user requirements from the perspective of each of the stakeholders separately, we engaged in a process where representatives of all the stakeholder groups collaborated on identifying the necessary requirements for supporting the activities of a learning environment.
The method for articulating these activities and their corresponding requirements was based on the practice of scenario based design.  To start the process we agreed upon a set of activities characteristic of learning environments.  These activities, or function groups are listed below.  

FIGURE 7: ACTIVITIES OF LEARNING ENVIRONMENTS
The function groups listed above served as an organizational canvas on which multiple scenarios were painted.  For each function group, several scenarios were described.  From each scenario, we extracted the user requirements for supporting such a scenario online, the assumptions embedded in the scenario, and any issues raised by the scenario that the project must address.  The heart of this document elaborates on the user requirements and design assumptions gleaned from the scenarios.  These requirements will be described in more detail in the following chapter.


2.3 design structure


Based on the design context and on the user requirements collected, some preliminary decisions were made regarding the structure of IMS environments.  Two of these will be discussed here:  containers and the general architecture of IMS environments.
Containers

Containers encapsulate a given amount of content, whether through literally containing the information or through providing a reference for the information needed.  Content may consist of primary elements (text, graphics, movies, tools) and/or additional containers.  In this way, containers may be added together, or aggregated within a larger container.  The contents of a container may be sequenced according to different rules and criteria.  The pictures below are physical representations of a container and its design function (namely to encapsulate information together).  The image on the left depicts a simple container with primary elements of movie clips, html pages, text, and an assessment test.  The image on the right depicts a more complex container with primary elements in addition to nested containers of learning resources.

               

        FIGURE 8: CONTAINERS FOR LEARNING RESOURCES

In order to facilitate the discovery, storage, and retrieval of containers, each container will have a set of metadata.  The metadata of a container serves as a label on a can describing its contents.  
       
FIGURE 9:  METADATA FOR A LEARNING RESOURCE
By describing metadata about like contents in a similar manner, users will have more tools available to them for locating appropriate learning resources.  Metadata will also be used to manage the distribution and use rights of a container.

Architecture
Software that implements the IMS Specification is known as an IMS environment.   The IMS environment facilitates interactions and manages access to and delivery of content. The IMS environment also takes care of automatically creating and destroying temporary IMS containers in support of developing and learning activities.
An IMS environment normally performs its responsibilities from a server in conjunction with a Web server, therefore supporting users with any standard Web Browser.  However, the IMS Specification will not assume World Wide Web clients exclusively. Future operating systems and environments may provide non-World Wide Web user interfaces, such as virtual reality, for navigating data including HTML information.
An IMS environment can run on a single system disconnected from the network, but must be able to carry out network-based communications when and if the system is re-connected to the network.  Some of the IMS environment's functionality may be distributed around a network to other servers or to client systems.  An IMS environment may communicate with one or more IMS environments to exchange information.  The diagram below depicts the different types of configurations supported by the IMS Specification.

FIGURE 10:  IMS ENVIRONMENT CONFIGURATIONS

Connection A, above, shows two IMS environments exchanging information.  Connections B, C, and D all depict the IMS server environment communicating with a client.  Connection B is a thin client, whereas in Connection C and D, part of the environment responsibilities are shared with the client.  Connection C represents the case of a client computer that is not continually connected to the network and may receive the bulk of its content through other means, such as a CD-ROM.  This configuration, however, still must support network communication, even if only sporadically.


anno02 Self-evident

2


3

IMS Project Requirements                Requirements


3. Requirements


overview

This chapter is the core of the document.  Here we will present the list of user requirements organized according to feature sets.  The feature sets will be described in turn, any assumptions regarding the features will be expressed, and then the requirements that engender these features are listed with italicized examples when appropriate.  The feature sets organize the requirements according to functionality.  There is not a one-to-one correspondence between requirements and features, and several of the requirements could support more than one feature set.  For organizational purposes, however, we have chosen to put requirements in only one category rather than replicate requirements throughout the document.

Within each category, or feature set, the requirements are listed in rank order, from those that are essential to any implementation of an IMS-compliant system, to those that are secondary-i.e. while desirable they are optional and may or may not be implemented in a particular IMS-compliant system, and, finally, to those identified as "do not preclude" - i.e. requirements that may at some time be useful, and should not be prevented from being implemented by virtue of decisions made during the design process. A fourth class of requirements were identified during the creation of this document that were considered to be outside the scope of the IMS specification. These requirements are listed in section 4 on Implementation.


3.1 Group management


Group Management features organize the membership or enrollment in a group or class and customize what type of information and activities are available to the members of the group.  A formal example of group management is the process of course design where prerequisites or enrollment criteria are set, resources are chosen, and the content and activities for the group are structured.  Group formation does not need to always be at the level of a course, however, and groups may form on a very ad-hoc and temporary basis.

For formal groups, such as courses offered by a University, a key assumption behind the requirements listed here is that institutions have made large investments in their administrative systems.  IMS environments should interface with these systems for the purposes of registering students and recording grades and other student information.

3.1.1 Essential Requirements


3.1.1.1 Enable teacher control of offering access:
  enable teacher to set "prerequisites" among offerings
anno1.
3.1.1.2 Variable start and stop of offerings
:  enable multiple learners to start and end offerings at variable times subject to the provider's constraints.   Users should be able to engage in asynchronous education
anno2.
3.1.1.3 Provide timing flexibility:
IMS should support variable times for start and end of offerings
anno3.


The introductory accounting offering at the University of Michigan is scheduled to begin at the start of the semester in September; the introductory accounting offering at Xerox University is scheduled to begin on the first Monday after the offering reaches full enrollment.


3.1.1.4 Enable the distinction between an offering and an instance of an offering
.


George searches Yahoo for Metaphysics courses being offered at accredited Universities.  George connects to the IMS environment at the University of Wisconsin and joins his Philosophy class for the weekly lesson.


3.1.1.5 Allow users to perform searches by location
:  allow user to confine search to particular directories or repositories when supported by the search service.


Rachel looks for training development courses offered by the US Military.


3.1.1.6 Enable posting and controlling access to information
:  IMS implementations must enable teachers and learners to post information they create for learners and set the access rights for them
anno4.
3.1.1.7 Two-way communication between enrollee and owner
:  IMS specification will facilitate two-way communication between an applicant/enrollee and the IMS environment owner
anno5.


John's application for admission to an IMS offering within the University of Michigan's IMS environment lacks information or certification required for admission. U of M will be able to contact John to request the necessary information.


3.1.1.8 Interface with existing enrollment information:
  the IMS specification will provide for interfacing with existing enrollment information  (e.g., there are existing specifications for transmitting enrollment information such as AACRAO's SPEEDE ExPRESS
anno6).
3.1.1.9 Allow owner to accept or reject enrollment requests:
  IMS specification will allow IMS environment owner to accept or reject enrollment request for an offering
anno7.
3.1.1.10 Interface with administrative systems:
transmit enrollment data to student records system
anno8.
3.1.1.11 Permit exchange of administrative data:
IMS will specify a data format for exchange of data (to and from) with significant existing administrative systems (e.g., PeopleSoft, SCT Banner, etc.) and standards (e.g., AACRAO EDI
anno9).
3.1.1.12 Interface with online library systems
.


Professor Hardy puts several journals and text from the library on reserve for his students to access online.


3.1.1.13 Assign users to groups
: IMS specification will enable assignment of users to one or more groups
anno10.


Jon is a student at Williams College majoring in history and music. If the Cornell IMS were to classify groups of students based on major, Jon would be the member of two groups.


3.1.1.14 Communicate group membership information:
the IMS specification will include a format and protocol for communicating group memberships among IMS environments
anno11.


The University of Toronto biology dept. strikes a site license deal for biology students. The University of Toronto IMS will be able to differentiate biology students (eligible for the site license) from those who are not a member of the group (and are, consequently, not eligible for the site license).


3.1.1.15 Enable anonymous participation
:  allow anonymous participation by any user at the discretion of whoever is assuming the role of teacher(s
anno12).
3.1.1.16 Allow users to switch roles seamlessly
.


Frank switches between designer status and student status while creating his course in order to view things from his students' perspective.
Kento enters the informal chat room under an alias but when he posts his assignments to the discussion board, he chooses to use his name as an identifier.


3.1.1.17 Provide instructor status information:
in an instructor-led offering, the instructor can check status of static and dynamic information about the offering (e.g., course description (static), number of students admitted (dynamic
anno13)).
3.1.1.18 Provide notification:
IMS environment includes notification capabilities according to a default set of rules
anno14.


The University of Colorado IMS is configured to send all notices to users via e-mail and notices are generated when work is complete on an offering and when new containers are made available.
Washington State University IMS is configured to send notices to users via their personal web pages (i.e., the first page that shows up when a user logs on to the WSU IMS); notices are generated only when new containers are made available.


3.1.1.19 Provide navigation capability:
System will allow navigation within and among containers according to whatever sequence has been established by a developer
anno15.


George is an instructor and developer. He selects a series of containers for an offering he's preparing. He specifies a sequence for those containers. Alex is a student in George's course. When he logs into the IMS at his institution, the offering is presented in the order George specified.


3.1.1.20 Linear sequence default
:  the default sequence for use of the contents is the order of the contents
anno16.
3.1.1.21 Enable individualized resequencing for progression through an offering:
  sequencing can be dynamic and individual.  Instructor may be able to have a default sequence and also tailor sequences to particular learnersanno17.

3.1.2 Secondary Requirements


3.1.2.1 Enable notification:
user can specify notification rules including input, criteria (conditions of IMS metadata, and action (notifying who and how
anno18)


Instructor Joe establishes a rule saying if the number of students in a class exceeds 15 the system should send him an e-mail indicating this status.


3.1.2.2 Enable triggered notifications
:  enable the existence of a specific state to trigger a notification or an event (such as an assessment or a branch
anno19).  


Suzie takes a test and scores poorly.  The instructor had set a flag for him to be notified if a student's performance drops below a certain level. IMS sends a notification to the instructor.  The instructor communicates with Suzie and modifies some aspect of the course to better meet her needs.


3.1.3 Don't Preclude


3.1.3.1 Enable non-linear sequences of containers:
  IMS containers specify how their internal containers will be opened in a nonlinear sequence
anno20.

3.2 personal profile management


Features of the personal profile relate to how an individual user manages and maintains records of his or her interactions and progress within an IMS environment and with IMS content.  The personal profile consists of user identification information, performance records, portfolio work, and preference information that may customize their IMS experiences.


3.2.1 Essential Requirements


3.2.1.1 A user may have one or more IDs
: user must have at least one ID and may have multiple IDs
anno21.
3.2.1.2 Identify users consistently:
  every user in the system needs to be uniquely identifiable in a consistent format and the ID allocation must be scaleable and distributed across multiple organizations (no single organization controls IDs
anno22).
3.2.1.3 IMS will allow a user to self-identify to an IMS system
anno23.
3.2.1.4 Track applications:
the IMS will  track and report information about learners and their status in the enrolling/application process
anno24.
3.2.1.5 Notify learners:
the IMS specification will enable the provider  to inform the learner of the status of an application at each threshold (receipt, support document collection and admission decision
anno25).
3.2.1.6 Users have access to their own user records
anno26.


Eric has completed a series of IMS offerings with UNC. He can review the records associated with those offerings, as well as his general user profile (e.g., name, e-mail address, etc.) at any time.


3.2.1.7 Access to performance information:
  advisor must have access to the user's performance information.
anno27


An advisor reviews a student's grades to determine if the student's math skills are adequate to pursue studies in physics.


3.2.1.8 Privacy of performance information:
  the privacy of performance information must be maintained.
anno28


A student grants access rights to a specific advisor to review only his mathematics course grades.  


3.2.1.9 Enable access to advisory support materials:
e.g. student records, university catalog, course records, IMS-compliant offerings
anno29.  
3.2.1.10 Protect personal data:
the transmission of personally identifiable information and credentials must be secure
anno30
3.2.1.11 Accumulate user information:
user information (profiles, portfolios, certification records, etc.) should accumulate within an environment
anno31.
3.2.1.12 User records should be extensible:
(e.g., as with metadata, you can add more fields).
anno32 User data is packaged within a container's contentsanno33.

3.2.2 Secondary Requirements


3.2.2.1 Allow user to point to existing IMS profile:
  IMS will allow a user to specify the location of an existing IMS profile
anno34.


Arthur has an established IMS profile with UNC, but is interested in registering for a course with the IMS system at Cornell. When registering with Cornell, Arthur can specify the existence and location of his UNC profile rather than create a profile from scratch.
Note:Arthur can specify the primary location for his records. Any secondary, tertiary, etc. locations must submit updates to the primary location. The primary location will update his records based on the updates they submit. We may use the AACRAO EDI data format standards for transcripts.


3.2.2.2 Permit controlled access to user profiles:
The environment will allow learner access to the roster/profile of other learners using the system, given permission of other learners
anno35.


Seventeen learners are enrolled in Physics Tutorial with ITP Learning Services. Among the 17 are Wesley, Paul, and Suzanne. Suzanne is a private person and doesn't want her peers to know that she is participating in a tutorial; Wesley and Paul are happy to tell people what they're up to. All three can see that 17 learners are enrolled, and each can see the names and profiles of learners who have not blocked their identities from their peers - i.e., all (including Suzanne) can see name and info on Wesley and Paul; no learner can see Suzanne.


3.2.2.3 Support multiple locations for user data:
when you register at an implementation, you specify a primary location where your user data are held or create a new record. If you reference a primary location, updates to those data will be submitted by the secondary, tertiary, etc. implementations; the primary location will update the records. (All locations will maintain records
anno36.)


Jeanne establishes her primary user record and takes an IMS course at the University of Chicago. She then enrolls at the Johns Hopkins IMS and specifies that U of C is her primary record holder. All results of her IMS work at Hopkins will be submitted to U of C and U of C will update her records; in addition, Hopkins will maintain its own records.


3.2.2.4 Personal profiles can be copied by the user:
user can keep a duplicate copy of their personal profile locally. This profile can be utilized to log on new IMS systems
anno37.


Jon has been enrolled in two IMS environments (UNC and CSU) and keeps a copy of his IMS personal profile on the hard drive in his Apple PowerBook. When Jon enrolls at University of Iowa, he can complete the application for enrollment process by uploading the data file from his hard drive. (In a case where Jon submits the personal profile to an IMS environment where he had already been enrolled, the server identifies him as a previous user, updates his records if necessary, and uses his server-based profile.


3.3 activity management


Activity Management features facilitate how the user actually engages with the IMS environment.  Whereas Group Management features establish the parameters of an abstract interaction, the Activity Management features manage the implementation or specific instance of this interaction (i.e. the difference between the syllabus description and the actual class session).  The Activity Management features also address communication and collaborative activities between users.


3.3.1 Essential Requirements


3.3.1.1 Seamless transitions between offerings and services:
  ability of one or more users to move easily between various offerings and services in the IMS environment. A "seamless transition" implies the smooth transition of program behavior during transition from one container to the next, or one procedure to the next.  Seamless does not refer to the appearance or behavior of the user interface
anno38.


A student has finished a module from Bear Publishing Company and clicks on the task bar to move to the next module provided by Lunar Technologies.  Each company's logo identifies the module's source.


3.3.1.2 Enable dynamic resequencing
anno39.
3.3.1.3 Enable self-paced progression:
  allow learners to control their  progress through materials at paces they set within the limits set by the teacher
anno40.
3.3.1.4 Enable a log history of the user's progress across containers
:  IMS environment can record event information to enable learners to review their path among containers (how they got where they are), completion state (how much of the offering they have encountered), performance  (assessment reports), and collaboration (evidence of interactions with other learners).  Retracing the path among containers constitutes backward navigation
anno41.  
3.3.1.5 Enable system marks:
  enable the learner to mark where he or she wants to return to within an IMS system .  This enables learners to leave the system and return to the same point in the system (bookmark
anno42).   


A learner closes down his or her computer having partially completed a list of questions on an assignment.  When the learner logs back onto the IMS compliant environment, the user's position in the list is restored.  Because  the system also tracks and records the user's progress, the answers completed thus far by the user are also presented.


3.3.1.6 Track usage in standard format:
  IMS implementation will track usage (i.e., # of retrievals, person retrieving, date and time, transaction ID) of containers in a standard format
anno43.
3.3.1.7 Enable the recording of advice
anno44.  


A learner accesses the record of an advising session to help recall strengths and weaknesses when deciding an elective course to take.
An advisor accesses the record of a previous advising session in preparation for another meeting with the same learner.


3.3.1.8 Enable teacher to track anonymous users
:  when a user has assumed anonymity, their activity may or may not be tracked at the discretion of the person assuming the role of the teacher
anno45.
3.3.1.9 Enable rapid interactions between users within the IMS Environment:
  allow the advisor and the advisee to exchange information quickly within the IMS environment
anno46.


An advisor assembles a note with electronic clippings from the course catalogue and information on a professor into a container which is sent to a student.


3.3.1.10 Support synchronous and asynchronous communication:
  IMS supports both synchronous and asynchronous interactions among individual users and groups (one-to-one, one-to-many
anno47).


Synchronous´┐Ż Enable multiple learners to access a given container and interact with one another within a container at the same time.  Users should be able to explore offerings together in a synchronous manner.  
Asynchronous--- Multiple learners should be able to access a given container and interact with one another through asynchronous forms of communication such as bulletin boards, listservs, email, peer review of each other's work, etc.


3.3.1.11 Enable communications among users:
  learner needs ability to communicate with other learners, instructors, experts in the field and other collaborators
anno48.


A learner requests clarification of an assignment by a teacher.  The teacher responds with a container which contains a message and an example.


3.3.2 Secondary Requirements


3.3.2.1 Record event and path information within containers:
  an IMS compliant environment can record event and path information within containers
anno49.


3.4 assessment and certification management


The management of assessment and certification entails tracking, reporting, and recording information about a user's progress and performance.  Both assessment and certification activities may take place either within an IMS environment or outside an IMS environment.  The requirements listed here address how assessment or certification information travels within or between IMS environments.


3.4.1 Essential Requirements


3.4.1.1 Enable storage and retrieval of assessment data:
  the individual performing the assessment  should have the ability to record the assessment data. Assessment data can be of various types and of variable length (e.g. numeric, alpha-numeric, variable length text
anno50).


The performance of a learner on a normed test, or a written critique, or an evaluation form.


3.4.1.2 Enable storage and retrieval of learner's progress:
  enable the storing and retrieving of learner's progress across containers
anno51.


Professor Lopez can monitor her students progress, as individuals and as a group, via progress reports sent to her regarding participation/completion information of each module and the students' scores determined through various assessment instruments.
Professor June retrieves a learner's progress record to see where they are in the course offering and how much time they have spent doing various assignments.  She uses this to evaluate areas of difficulty for the learner.
Kym takes a self-assessment test in an online course to determine what section of the course she should progress to next.
Students conduct a peer review of each other's work on an assignment completed at the end of a group project.


3.4.1.3 Enable containers to hold only assessment tools:
  enable creation and connection of containers that hold only assessment tools
anno52.


The Educational Testing Service creates an IMS compliant pre-test for the SAT
A psychology professor creates a Learning Style self-test to help the learner identify strategies work best for her.


3.4.1.4 Enable assessment tracking and reporting:
  track and report assessment for an individual and/or a group
anno53.


The instructor or learner can print out a summary of the learner's assessments for the course.  A learner or teacher can print out a summary of the assessments of the teacher in teaching this course.


3.4.1.5 Assessment may occur without IMS supported learning being involved
anno54.
3.4.1.6 Provide certification token format:
the IMS specification will include a format for a certification token that will be appended to a user's profile upon completion of an offering
anno55.


Rob successfully completes an introductory French offering on the University of Iowa IMS. Upon completion, a "token" is added to his profile indicating that he has completed the offering successfully.


3.4.2 Secondary Requirements


3.4.2.1 Enable reporting for institutional assessment:
  enable assessment tracking  and reporting  data to be aggregated in reports for institutional assessment (such as regional accreditation). Such data may include: Number and characteristics of people attempting and completing an offering; Success ratings of completion; Time required for those completing offering; Aggregation of offerings used in an institution as a list with descriptions
anno56.
3.4.2.2 Provide consistent scaling of numerical data
:  IMS will provide consistent  scaling for numeric data by recording  results within a range of 0-100. If the assessment value is recorded numerically, the correlation among assessment tools is enabledanno57.


3.4.3 Don't Preclude


3.4.3.1 Enable diagnostic assessment
:  enable pre-assessment measures to determine what the learner knows and what the learner needs to know (diagnostic assessment
anno58).


3.5 content management


Content Management features embody requirements for the creation and use of learning materials and tools for individuals and groups.  The bulk of these requirements address the need for metadata in order to label content and determine what a user may or may not do with this requirement.  In IMS terminology, content is wrapped in an IMS container; i.e. all of the elements within a container have some relationship to each other and are offered as a whole.  

Two important assumptions regarding the development of content is that users will be able to create content with standard authoring tools and the ease in making this content IMS compliant is an important consideration for the success of IMS.  As for the evolution of metadata, the specification assumes that a base standardized vocabulary is important for initial use, but these fields and values will be further refined as the market determines.

3.5.1 Essential Requirements


3.5.1.1 Provide functions to create/manipulate containers:
IMS environment contains callable function to create a container, insert fields in a container, and set values within a field
anno59.
3.5.1.2 Permit multiple versions:
IMS environments must allow multiple versions of the same container to exist in the same implementation simultaneously
anno60.


An offering for introductory astronomy is available in time for the 1996 school year. In early 1997, a new version is released. The University of Michigan wants to make the new version available on its IMS, but does not want to replace the 1996 version - since it may still be in use by some classes.


3.5.1.3 IMS container IDs are created by IMS implementations as needed
:  The creation and assignment of IMS IDs as metadata to a container is transparent to the user
anno61.
3.5.1.4 Containers are responsible for the sequencing of their contents:
IMS containers specify the order in which their internal containers will be opened
anno62.


The sequence of internal containers may be linear, random, or altered based on user input and procedures with the container.


3.5.1.5 Non-IMS external references can be used:
  users are free to reference (link to) content and environments that are not IMS compliant. (e.g. could include a URL
anno63)


A user clicks on a reference within an IMS compliant application and links to a non-IMS compliant web page.
Student is completing an on-line IMS course, he goes outside the course to research a topic.  When he identifies the best instances of additional information (e.g., on the web, digital library or a CD), he creates links or references in the IMS environment that he and other colleagues can use.
A user clicks on a button and runs a Hypercard application from the local hard disk.


3.5.1.6 Containers can be created without entering metadata values
:  A container  must contain fields for metadata, but it can be made on the fly without any input of the metadata values.  These containers are non-IMS compliant
anno64.


A developer is using an authoring tool to complete the second version of a working prototype of an application.  She containerizes the prototype so she can test it "off line" without having to enter all the metadata necessary to make it IMS compliant.


3.5.1.7 Provide packaging method:
the IMS specification will establish a method for packaging to enter at least the minimum required metadata and to make something IMS compliant
anno65.
3.5.1.8 Ensure uniqueness of identity for IMS compliant containers
:  IMS containers from various providers and organizations must be uniquely identifiable.  While this may require one or more Issuer ID Registries to register the IMS ID issuer component of the composite IMS ID (cf. Ethernet hard address vendor registration), other solutions are encouraged anno66 .  


Omicron Registration Services along with 4 other companies have been selected by the IMS Project to become IMS ID registry services.  XYZ Corporation, who is developing an IMS environment product, contacts Omicron and receives an IMS ID Issuer ID.  XYZ uses their IMS Issuer ID along with a unique serial number as the complete IMS ID for each copy of their IMS environment that they sell.


3.5.1.9 Offering profile data is required
anno67.
3.5.1.10 Metadata is organized in fields
: the user may search for IMS compliant containers by categories (keywords, objectives, subject, learning style) and criteria(time involved, payment method, brand type of materials
anno68).
3.5.1.11 There is a minimum set of metadata fields for every metadata record
anno69.
3.5.1.12 Enable standardized and non-standardized terms for metadata:
Indexing materials and services may occur through a standardized or non-standardized vocabulary
anno70.
3.5.1.13 All metadata is publicly accessible for browsing by non-proprietary search engines
: The user must be able to view all the public/browsable IMS metadata for a container
anno71.
3.5.1.14 Metadata format is public knowledge
:  enable access to information about an offering through consistent formats
anno72.
3.5.1.15 Provide content descriptors:
every container has a content descriptor (text) that describes the content of the container. The content descriptor is part of the metadata
anno73.
3.5.1.16 All containers have a current version date
anno74.
3.5.1.17 Provide information for users' special needs
:  offerings that accommodate users' special needs should indicate relevant information. Provide information about the delivery of educational offerings that is of value for users with special needs
anno75.


A learner with limited sight may be searching for offerings with an audio mode or enlarged display mode.


3.5.1.18 Indicate display requirements:
metadata must include sufficient information to allow appropriate display of an element on the client machine given that the client has appropriate software installed
anno76.


An offering includes a TIFF image as an element. The environment will communicate the presence of the TIFF to the client machine and, provided that a TIFF viewer is present on the client machine, the TIFF will be viewable.


3.5.1.19 Provide element lists:
an IMS container can include a list of authentic or primary elements (i.e. ones that are not containerized) with their associated copyrights and ownership information
anno77.
3.5.1.20 Allow for extensibility of metadata:
(e.g., additional metadata fields may be added at a later date; the length of metadata fields may be extended at a later date).  Publishers and institutions may have their own metadata fields that they wish to have
anno78.
3.5.1.21 Field content types are extensible:
the field types are extensible and a method of identifying those field types will be defined in an extensible way (e.g., much as additional MIME types can be added within a browser
anno79).
3.5.1.22 Enable the ability to search non-textual databases in an appropriate manner.


Sylvia finds a picture of the Mona Lisa and submits it to her favorite search engine with the request to "find more pictures like this."


3.5.1.23 Enable the ability to search within a container
:  Enable the ability to search within a container and/or to extract information from a container  (e.g. searching by MIME type or by key words).


Dr. Shumaker purchases an offering for his students on pediatric anesthesiology.  He searches the container for relevant and important terms that he indexes and links to a glossary supplied by the American Association of Pediatrics.


3.5.1.24 Enable the creation of run-time and design-time containers
:  Run-time containers will have set properties and design-time containers with open properties.
3.5.1.25 Aggregation of containers
:  a container's ability to be aggregated is determined and specified by the developer (or owner) of the container.  A container with the aggregation ability can be placed into another container
anno80.


Professor Xavier created a simulation container that allows students to conduct an archaeological dig.  He has allowed the container to be aggregated (included) by anyone creating educational courses.


3.5.1.26 Disaggregation ability of containers
:  a container's ability to be disaggregated is determined and specified by the developer (or owner) of the container.  A container with the disaggregation ability can be separated into different containers (generally for use in other containers
anno81).


Professor Xavier's archaeological simulation container (see above) has several image containers within it.  He has specified that these image containers cannot be disaggregated (used separately) from his entire simulation container.


3.5.1.27 Re-sequencing ability of containers:
  a container's ability to be sequenced is determined and specified by the developer of the container.  A container with resequencing ability allows its internal containers to be reordered and/or excluded
anno82.


Professor Xavier (see above) allows the user of his archaeological simulation container to determine in what order they will encounter various images.


3.5.1.28 Redistribution ability of containers:
  a container's ability to be redistributed is determined and specified by the developer of the container.  A container with redistribution ability may be taken by someone other than the developer and distributed to other developers
anno83.


Professor Xavier (see above) has disabled the redistribution feature of his archaeological simulation container; therefore, other people can use and/or aggregate the simulation container, but they cannot redistribute it to other developers.
anno84


3.5.2 Secondary Requirements


3.5.2.1 Enable preview function
:  IMS specification enables access (preview functionality) to the contents of the container.  Owner may specify variable access to the preview functionality
anno85.


An instructor who has a special pre-release agreement with a publishing company is able to browse offerings not available to the general public.
An instructor whose institution has a special licensing agreement with a provider can view different pricing information about offerings than others.  


3.5.2.2 Preview function controlled by provider
:  The content provider determines response to a preview request
anno86.


User asks for a preview and gets a page of text and graphics explaining the offering in more detai, or a limited function version to try out, or a video about the offering.


3.5.2.3 Enable parental control tags:
  IMS will enable tagging of data to permit parental control of access (current and future standards for parental control standards
anno87.)
3.5.2.4 Permit copying of containers:
a user may copy a container from one IMS environment to another as permitted by the owner of the container
anno88.
3.5.2.5 Enable developers to export any data in IMS compliant containers:
Containers can create their own IMS-compliant metadata containers that are extensible and unspecified by IMS
anno89.


ETS establishes an IMS container format for SAT results: date, ETS public key, score, location, etc. If ETS publishes the format, institutions might then query the container for the contents of the score field.


3.5.2.6 System must maintain a linkage between versions of the same container
anno90.


A 1996 and 1997 version of an offering on how to prepare corporate income tax returns are available. It should be clear that these are two versions of an offering, rather than discrete and unrelated offerings


3.6 Commerce and licensing management


Commerce and Licensing features are supported by requirements concerning the distribution and use of content and/or the provision of services.  The transactions that take place may result in costs for the user or the content/services may be free of charge.  The requirements below facilitate the consumer's decision whether or not to engage in a financial transaction and also facilitate the developer's ability to track the usage of content/services.

A core assumption of the requirements listed below is that educational organizations and content distribution companies have a large investment in their administrative systems that support business transactions.  Therefore, IMS implementations should provide an interface for these systems in order to complete transactions.
  


3.6.1 Essential Requirements


3.6.1.1 IMS specification will allow for transfer of ownership of a container
anno91.
3.6.1.2 Only IMS compliant containers are distributable
anno92.


Dr. Allen browses a collection of IMS containers. He retrieves a container and it is transferred into his IMS environment where he can then begin working with it to incorporate into his course.


3.6.1.3 Transactions are not required to browse container metadata
anno93.


XYZ Publishing maintains an IMS environment accessible via the public Internet and all visitors can browse through their offerings looking at title descriptions, etc.  Orion Business Research Corp. maintains an IMS environment that only subscribers have access to.  Orion subscribers pay for access to the Orion site where they can then browse without paying a fee.


3.6.1.4 Browsing can be done without an IMS user profile ID
anno94.
3.6.1.5 Support transactions for IMS compliant containers
:  only IMS compliant containers can be transacted within and between IMS environments
anno95.


IMS will not recognize a standalone web page or a standalone GIF image as something that can be transacted.


3.6.1.6 Specify transaction data formats:
IMS will specify a data format for transaction information to and from a hosting organization
anno96.
3.6.1.7 Interface with back-office solutions:
  develop the IMS specification to interface with a gateway to existing back-office solutions (royalties, copyright, accounting, etc
anno97.)
3.6.1.8 Control financial behavior or container:
Financial behavior of a container cannot be changed by the aggregator or the user, but can be changed by the owner
anno98.


ITP owns a container which is aggregated into a larger offering by a another publishing company. The container from ITP that the second company aggregates retains the financial behavior (i.e., cost, payment rules, etc.) that they had previously. (NB: If the second company is looking for a container with different financial behavior, and can reach agreement with ITP, one could be created specifically.


3.6.1.9 The owner can specify the level of permitted aggregation/disaggregation
anno99.


ITP can indicate that a container that it owns can or cannot be aggregated. ITP can also specify whether a container that it owns can or cannot be disaggregated.


3.6.1.10 Provide a "time to live" capability:
"time to live" metadata item of a container can be overridden on a per transaction basis based on the terms of purchase between user and the hosting organization
anno100.


John buys an IMS offering for his Astronomy 101 course. The offering has a "time to live" setting that will grant access for the current semester. The hosting organization can change the terms and grant access for a different period of time - either longer or shorter.


3.6.1.11 Provide start/stop dates
: Transactions may include start and/or stop dates that determine a window of time during which a user can access to an offering
anno101.
3.6.1.12 Calculate aggregate costs:
enable the aggregation of total cost for an offering (e.g., as a hosting organization assembles an offering, the environment will calculate the sum of the costs of each container in the offering; the hosting organization can use this as the price for the offering, or set a different price
anno102).
3.6.1.13 Provide information about terms and conditions:
IMS hosting organization will inform the user of payment, terms, and refund policy when the user makes the purchase decision
anno103.


Philip buys an offering from the ITP IMS. At the time he makes his purchase decision, ITP will inform him of payment, terms, and refund policy.


3.6.1.14 Check if aggregation permitted:
the IMS specification should allow aggregators to ascertain if the copyright holder permits aggregation
anno104.
3.6.1.15 Provide aggregation metadata elements:
since the following information must be submitted with an aggregation request, metadata elements for aggregation should include: what is the source project, author, publisher, title, ISBN, edition, exactly what material is wanted, which affiliations(s) will use the materials?, what is the maximum number of copies to be made available, period of time for use (term), what percentage does this represent of the whole project
anno105.
3.6.1.16 Permit fee for service and/or fee for material:
IMS specification will permit fees for service (e.g., browsing) and fees for material (e.g., content
anno106).


Note: A hosting organization may choose to charge fees for service, fees for material, both, or neither


3.6.1.17 Handle different payment methods:
multiple payment methods are stored in the user profile. User can specify which payment method he/she wants to utilize with each transaction, though a default method of payment may be specified in an environment
anno107.


David's profile includes a VISA credit card, national learning subsidies (learning stamps), financial aid, cash, and other payment methods. The hosting organization will determine which forms of payment are acceptable and will be handled by the institution in their normal manner.


3.6.1.18 Enable transactions at different points:
Points of transaction (costs) may occur at either the use level, access level, or aggregation level
anno108.


Billy gets charged for the cost of all the nested containers because he access to the parent container rather than getting charged individually as he uses them
Johnny only pays for the containers he actually opens within the course offering, because this is how the offering has been packaged.


3.6.1.19 Enable affiliated and nonaffiliated electronic transactions
anno109.


College of Bill and Mary pays for unlimited access for all its students to the offerings of EPC corporation.
John pays for access to an offering that he wants to use on his own system  at home.


3.6.1.20 Confirm transactions:
user will be prompted to confirm or reject a transaction
anno110.


A dialog box is displayed before a Jon's account is charged for an offering asking him to confirm the transaction.


3.6.1.21 Financial transactions can be canceled only while they are pending
anno111.


Jennifer selects a writing offering from the ITP IMS and indicates that she would like to pay by check. Her transaction status is "pending" since payment has not yet been confirmed. She will have the option of canceling the transaction until such time as it is confirmed. After the transaction has been confirmed, any cancellation is subject to direct contact between Jennifer and ITP.


3.6.1.22 Access to content may be granted in any state of transaction:
to be determined by the content owner
anno112.


ITP is a company that offers its customers access to its offerings within an IMS environment once s/he indicates an interest in purchase (i.e., the transaction is pending) and, of course, after the transaction has been confirmed; Faulkner Publishing (fictional) requires payment to be confirmed before access is granted to its offerings within an IMS environment.


3.6.1.23 Permit secure/insecure communications:
any type of communications in the IMS system may be secure or may not be secure at the discretion of either party in the transaction
anno113.


Jamie buys an offering from ITP. ITP specifies that the containers must be exchanged in an encrypted form.
Scott purchases an IMS offering from UNC using a credit card. Scott specifies that his credit card number be transmitted in encrypted form.
Elizabeth chooses CSU as her IMS provider. She submits tuition payment information to CSU but is not concerned about security.


3.6.1.24 Enable instantaneous/deferred transactions:
IMS environment will support transactions that are processed instantaneously and those that are processed non-instantaneously (e.g., off-line approval aggregation process, paying by check
anno114).
3.6.1.25 Default price of a container is "free".

3.6.1.26 Pricing may be static or dynamic.


Professor White searches for online manuals for his course.  He finds some materials from Bright Light Publishing that are listed at $20.00.  At a separate publishers' site, when he searches for materials, he is asked to submit a form identifying his institution before a price is generated and returned.


3.6.2 Secondary Requirements


3.6.2.1 IMS will track and report information about transactions:
(e.g., usage statistics, payment method).  This information must be kept under access control
anno115.
3.6.2.2 Permit verification of licensing compliance:
all transactions must be logged in a way that will allow verification of compliance with agreements regarding licenses
anno116
3.6.2.3 Specify confirmation preference:
User can specify whether or not they will be prompted to confirm or reject before a transaction. (e.g., dialog box
anno117).
3.6.2.4 Each transaction of a multi-party transaction is tracked separately
anno118.


Kevin clicks on a link on a web page within the University of Delaware IMS, but the link is for material hosted by ITP. The transaction between U of D and ITP is tracked separately from the transaction between U of D and Kevin.


3.6.3 Don't Preclude


3.6.3.1 Personal transaction history should be accessible by the user
anno119.
3.6.3.2 Automatically identify applicable discounts:
The IMS data format for transactions will include enough information such that the  IMS hosting organization's systems can automatically determine any special discounts that may be valid for the user
anno120.


Kirsten, a biology student, is working on her class assignment on the Web.  She clicks on a link that refers to a collection of biology web pages and Java applets on XYZ Publishing Corp.'s IMS environment.  Because Kirsten's biology department has a site license for the module in question,  Kirsten is not charged individually for access to the module.


3.7 security management


The security features of IMS are supported by requirements for identification, authentication, and authorization; i.e. the access controls (rights and privileges) for joining an IMS environment or using IMS resources.  The requirements for security pervade all the other feature sets as well, but for organizational purposes, they have been listed here as a separate group.


3.7.1 Essential Requirements:


3.7.1.1 Secure synchronous and asynchronous communications
: secure synchronous and asynchronous communications must be available.
anno121  


A teacher advises a student in a text message.  The message can only be accessed by the student.


3.7.1.2 Enable control for varied data access
:  allow the owner of information to determine who has access to how much of this information and what can be done with this information by whom
anno122.


John is applying for a job and is concerned that he may be viewed as over qualified.  John makes only a subset of his certifications viewable by the company to which he is applying.


3.7.1.3 Support multiple container access rules
:  support multiple rules of container access (browse, modify, read, create, copy, and destroy) based on user
anno123.


A learner can only use a container, and cannot modify it.


3.7.1.4 Access rights for metadata and the contents of containers are separate.
anno124


XYZ Publishing allows browsing descriptive information of all of its IMS-compliant offerings, but restricts users ability to get copies of the offerings to those that have subscribed to their service.


3.7.1.5 Access control for data items:
  Data items will be under read and write access control through an IMS environment programmatic interface
anno125.
3.7.1.6 IMS will adhere to accessing rules set within the system
anno126.


Within the University of Maryland IMS, Jonathan (a student) has access to offerings only for his coursework. Mary, an instructor at Maryland, has access to all offerings.


3.7.1.7 Provide authorization and authentication:
  IMS will enable authorization and authentication for both individuals and for group membership
anno127.


A provider of offerings ensures that a learner requesting an offering is who he or she says he or she is, and that the learner is authorized to use the offering as a student affiliated with a particular university.  


3.7.1.8 Support bi-directional authentication:
the system will support mutual authentication between sender and receiver
anno128.
3.7.1.9 Maintain authentication state:
the IMS specification will allow the user to navigate among containers within an environment without being re-prompted for authentication information
anno129.


Geoff works through an IMS offering composed of multiple containers within a single IMS environment. He is prompted for user ID and password when he first connects to the system, but he is not prompted for user ID and password when moving from one container to another. (The environment
may force a timeout period after which Geoff would be re-prompted).


3.7.2 Secondary Requirements


3.7.2.1 Support extensible rules of container access
:  enable the creation and use of rules, simple to complex conditions, to be used in determining if a user can access a container
anno130.


Professor Jones establishes an access rule that allows only students who have progressed through 50% of the course material and have a better than 80% average on their assessment results to access a collection of advanced materials.


3.8 technical Administration management


The Technical Management features are supported by requirements that address the overall infrastructure or architecture of IMS environments and content.  Similar to the requirements for Security, the requirements listed here pervade all of the feature sets of IMS.


3.8.1 Essential Requirements:


3.8.1.1 Support Existing Standards:
the IMS specification will incorporate existing industry and formal standards, when applicable
anno131.
3.8.1.2 Internet Standards
: the IMS Specification will be based on Internet protocols, standards, and formats, where applicableanno132.
3.8.1.3 Internet protocols between IMS environment and clients
:  use standard Internet protocols for data transfer between IMS environment and clients
anno133.
3.8.1.4 IMS defined protocols between IMS environments:
  IMS will define a protocol for data transfer between IMS environments; this protocol or protocols may be different from those used for data transfer between IMS environments and clients
anno134.
3.8.1.5 IMS protocol to make metadata readable:
  IMS will establish a protocol for making the metadata on containers readable (and therefore searchable) in ASCII by search engines
anno135.


John uses AltaVista to search the web for learning resources. IMS containers containing metadata matching his search criteria that reside on public web servers are included in the results set.


3.8.1.6 Enable Data Storage Interface
: the IMS Specification will enable implementations to define how they perform data storage and retrievalanno136.
3.8.1.7 Allow for varied computing models
: the IMS Specification will allow for IMS communication to occur irrespective of a particular computing model anno137.  


Two IMS-compliant containers may communicate with each other on a client and then transmit data back to a server.  An IMS environment may distribute part of its functionality to client machines and to intervening systems for load balancing.


3.8.1.8 Enable local host implementations:
  IMS specification enables local host (i.e., one computer acts as both environment and client) implementations of environments
anno138.
3.8.1.9 Allow intranet-based implementations:
  IMS specification enables intranet-based (i.e., not Internet connected) implementations of environments
anno139.
3.8.1.10 Containers can contain any type of data:
developers of IMS containers can incorporate any data or executable as the contents of a container, including applications from legacy software that may or may not require additional software on a user's system.  The metadata for such containers must identify the type of data
anno140.


If an author were to use a Quicktime movie in a container, then the metadata would include information to enable a user's Web browser (for example) to launch an appropriate helper application or plug-in.


3.8.1.11 Enable scaleable implementations
: the IMS Specification will enable scaleable implementations.  Scaleability implies but is not limited to avoiding centralized repositories for critical elements required for IMS compliance.  However, a registry for ID issuer is presumed (see other requirements in this section anno141).  
3.8.1.12 Facilitate creation of IMS certification services
anno142.


The IMS Project works with Software Testing Services, Inc. to establish a certification service that provides for 3rd party certification of IMS environments and containers.


3.8.1.13 Multilingual Implementations:
the design of the IMS specification will enable the development of multilingual IMS environment implementations
anno143.  
3.8.1.14 Each IMS environment will have its own ID:
  each IMS environment ID is composed of the Issuer ID and some issuer designated value (e.g., a Serial Number
anno144).
3.8.1.15 Allow alphanumeric name associations with IMS environment ID
:  IMS implementations can be named and the name can be different from the unique environment ID  (e.g. DNS system for IP addresses
anno145)
3.8.1.16 Provide consistent ID format:
every entity in the system needs to be identified in a consistent format and the ID allocation must be scaleable and distributed across multiple organizations (no single organization controls IDs
anno146).
3.8.1.17 Provide unique IDs:
there will be a standard composite ID format that will create a globally unique IMS ID for people, containers, organizations, etc
anno147.
3.8.1.18 Use composite IDs to ensure uniqueness:
the composite nature of all IMS IDs reflects a method of assigning a unique ID and does not necessarily reflect any meaning (e.g. location, organization, etc
anno148.)
3.8.1.19 Define standard error messages:
IMS specification will define a minimum set of error codes and associated messages
anno149.
3.8.1.20 Provide error-handling/propagation capability:
IMS specification will include a message protocol for modules to communicate errors which can be handled by the modules themselves. If the message is not understood by the module, it is passed up as a value and text to the next container level(s) and ultimately the environment level
anno150.
3.8.1.21 Display error messages:
IMS environment will display error messages passed to it from containers; a default will be displayed if no text message is available
anno151.


An error code is received by the environment that is unknown to the environment; a generic error is displayed.


3.8.2 Secondary Requirements


3.8.2.1 Develop a set of procedures that describe how to test for IMS compliance.
The IMS specification itself will be the basis for determining IMS compliance in the absence of formal test procedures. Test procedures would be developed after the initial release of the specification; a tool to automate the test procedures may be developed at a later date
anno152.


3.9 summary of requirements


The organization of requirements by feature sets was motivated by two objectives: 1) to place the requirements in the overall context of a functional learning system, and 2) to juxtapose like requirements in order to draw out the nuances of each requirement while, at the same time, contributing to a general understanding of the feature set's intended functionality.

Like most systems of classification, however, the requirements and the implied features do not fall cleanly into separate and discrete categories.  In fact, there is considerable overlap and dependencies among the different requirements.  The diagram below attempts to outline some of the most important connections between the requirements of the different feature sets.


FIGURE 11:  INTER-RELATED REQUIREMENTS

The above diagram depicts three important points regarding the inter-relationship between the feature sets used to organize the requirements.  First of all, the technical requirements act as a framework or infrastructure for holding all the requirements together.  Technical administration management requirements, such as using existing protocols or supporting multiple data types, affect all of the requirements. The second important point from the diagram is the centrality of the Group management requirements.  This centrality is a design principle that will be discussed more in the next section.  Finally, the depiction of the feature sets as modular parts reiterates the scalability and interoperability of IMS compliant resources.


anno03 Self-evidentanno1
3
4.7.1.4.anno2
3
4.7.1.5.anno3
3
4.12.1.24.anno4
3
4.7.1.11.anno5
3
4.9.1.1.anno6
3
4.9.1.4.anno7
3
4.9.1.5.anno8
3
4.9.1.9.anno9
3
4.12.1.12anno10
3
4.12.1.25.anno11
3
4.12.1.5.anno12
3
4.4.1.3.anno13
3
4.12.1.6.anno14
3
4.12.1.7.anno15
3
4.12.1.11anno16
3
4.6.1.7.anno17
3
4.7.1.3.anno18
3
4.12.2.24.anno19
3
4.3.2.2.anno20
3
4.6.3.1.anno21
3
4.4.1.6.anno22
3
4.9.1.2.anno23
3
4.9.1.3.anno24
3
4.9.1.6.anno25
3
4.9.1.7.anno26
3
4.12.1.23.anno27
3
4.2.1.2.anno28
3
4.2.1.3.anno29
3
4.2.1.4.anno30
3
4.9.1.8.anno31
3
4.12.1.5.anno32
3
As all metadata is public, user data must be within the container.  User data is NOT metadata, as user can define access rights.  This requirement could be out of scope unless the IMS project is going to define a standard student record.  This means the IMS project will be defining a standard container's internal structure.  anno33
3
4.12.1.21.anno34
3
4.9.2.1.anno35
3
4.12.2.3.anno36
3
4.12.2.6.anno37
3
4.12.2.8.anno38
3
4.7.1.1.anno39
3
4.7.1.2.anno40
3
4.7.1.8.anno41
3
4.7.1.9.anno42
3
4.7.1.10anno43
3
4.8.1.1.anno44
3
4.2.1.6.anno45
3
4.4.1.4.anno46
3
4.2.1.5.anno47
3
4.7.1.6.anno48
3
4.7.1.7.anno49
3
4.7.2.1.anno50
3
4.3.1.1.anno51
3
4.3.1.2.anno52
3
4.3.1.3.anno53
3
4.3.1.4.anno54
3
4.3.1.5.anno55
3
4.13.1.1.anno56
3
4.3.2.1.anno57
3
4.3.2.3.anno58
3
4.3.3.1.anno59
3
4.12.1.26.anno60
3
4.15.1.7.anno61
3
4.6.1.6.anno62
3
4.6.1.8.anno63
3
4.6.1.9.anno64
3
4.6.1.5.anno65
3
4.15.1.2.anno66
3
4.1.1.7.anno67
3
4.15.1.4.anno68
3
4.5.1.2.anno69
3
4.10.1.3.anno70
3
4.10.1.2.anno71
3
4.5.1.1.anno72
3
4.5.1.3.anno73
3
4.15.1.1.anno74
3
4.15.1.3.anno75
3
4.5.1.4.anno76
3
4.12.1.2.anno77
3
4.15.1.8.anno78
3
4.12.1.3.anno79
3
4.12.1.22.anno80
3
4.6.1.1.anno81
3
4.6.1.2.anno82
3
4.6.1.3.anno83
3
4.6.1.4.anno84
3
4.15.1.4.anno85
3
4.5.2.1.anno86
3
4.5.2.2.anno87
3
4.10.2.1.anno88
3
4.12.2.2.anno89
3
4.12.2.7.anno90
3
4.15.2.3.anno91
3
4.8.1.6.anno92
3
4.8.1.7.anno93
3
4.5.1.5.anno94
3
4.5.1.6.anno95
3
4.14.1.14.anno96
3
4.14.1.6.anno97
3
4.8.1.2.anno98
3
4.15.1.5.anno99
3
4.15.1.6.anno100
3
4.12.1.9.anno101
3
4.14.1.11.anno102
3
4.12.1.13.anno103
3
4.14.1.1.anno104
3
4.14.1.7.anno105
3
4.14.1.12.anno106
3
4.14.1.16.anno107
3
4.14.1.2.anno108
3
4.14.1.3.anno109
3
4.14.1.5.anno110
3
4.14.1.4.anno111
3
4.14.1.8.anno112
3
4.14.1.9.anno113
3
4.14.1.10.anno114
3
4.14.1.15.anno115
3
4.14.2.1.anno116
3
4.14.2.2.anno117
3
4.14.2.3.anno118
3
4.14.2.4.anno119
3
4.14.3.1.anno120
3
4.14.3.2.anno121
3
4.2.1.1.anno122
3
4.4.1.1.anno123
3
4.4.1.5.anno124
3
4.4.1.7.anno125
3
4.4.1.8.anno126
3
4.12.1.8.anno127
3
4.4.1.2.anno128
3
4.12.1.17.anno129
3
4.12.1.1.anno130
3
4.4.2.1.anno131
3
4.1.1.1anno132
3
4.1.1.2anno133
3
4.8.1.3.anno134
3
4.8.1.4.anno135
3
4.8.1.5.anno136
3
4.1.1.3.anno137
3
4.1.1.4.anno138
3
4.11.1.1.anno139
3
4.11.1.4.anno140
3
4.1.1.5.anno141
3
4.1.1.6.anno142
3
4.1.1.8.anno143
3
4.1.1.9.anno144
3
4.11.1.2.anno145
3
4.11.1.3.anno146
3
4.12.1.14.anno147
3
4.12.1.15.anno148
3
4.12.1.16.anno149
3
4.12.1.18.anno150
3
4.12.1.19.anno151
3
4.12.1.20.anno152
3
4.15.2.1.

This information is confidential and proprietary to the EDUCOM IMS Partnership and may not be disclosed without permission.


4


4. Implementation and Design Rationale


The requirements from the previous section represent a type of "wish list" generated by users and developers of online learning resources.  These requirements will serve as an outline of the functionality the IMS specification must enable.  The requirements and the resulting specification are guidelines for making resources that are IMS compliant.  IMS compliance ensures a level of interoperability and a level of support for essential learning interchanges.

The IMS specification, however, only defines formats and protocols for interchanges that occur within or interface with an IMS environment.  The specification does not prescribe how developers must implement the base functionality that is required.  This openness leaves room for innovation and the creation of additional requirements that will add value to the basic IMS framework.

The IMS project recognizes the need to implement its requirements and specification in order to refine the specification as well as provide a real-world example of the specification in action.  The IMS prototype is not the definitive way to implement the specification but will embody best-practice approaches in technical development and pedagogical design.  

The diagram below depicts how the IMS requirements feed into the specification which in turn result in an implementation.  The IMS prototype is one implementation and its creation will elicit more requirements as well as refine the specification.


FIGURE 12:  PROJECT DEVELOPMENT


4.1 recommended requirements


The IMS prototype is one implementation of the IMS specification and requirements.  Other developers and providers may implement the IMS specification in completely different ways and add more functionality through additional features.  As long as an implementation supports the base level of functionality prescribed in the specification, it will be an IMS implementation.

During the IMS requirements formulation meeting and during subsequent focus group meeings, a number of requirements were articulated that were considered important features of learning resources. These requirements were identified as desirable components, but not necessarily essential core components, for IMS offerings and environments.  This is not a conclusive list but suggests some of the features that will add value to the online learning experience.  For this reason, they are recommended requirements for IMS implementations and will most likely be addressed by the IMS prototype.

4.1.1 GROUP MANAGEMENT


4.1.1.1 Support web-based enrollment.
4.1.1.2 Enable on the fly customization of group tools, content, and membership.


4.1.2 PERSONAL PROFILE MANAGEMENT


4.1.2.1 The IMS specification will require modules to read user profile information from the environment.
4.1.2.2 Search arguments might be stored (for example in a profile) by intelligent search engines.
4.1.2.3 Enable browsing based on another person's profile with their permission


Reference librarian searching for a patron
Job counselor searching for a customer.


4.1.3 ACTIVITY MANAGEMENT


4.1.3.1 An IMS environment will avoid redundant data entry.  If information has been entered into the system, the system will use this information as a default value.


In the University of Michigan's IMS environment, students identify themselves by their personal ID number and password.  The individual course material is now personalized based on their registration records.


4.1.4 ASSESSMENT AND CERTIFICATION MANAGEMENT


4.1.4.1 Course evaluations can be sent to the teacher, or institution, or whomever.


4.1.5 CONTENT MANAGEMENT


4.1.5.1 Develop a tool to apply IMS metadata and package the container or containers as an offering.


An IMS metadata tool or content packaging tool may allow a content developer to answer a series of questions, specifying the values for metadata fields, and then package the offering.


4.1.5.2 Users should be able to view the name of both the content creator and content provider.
4.1.5.3 An IMS offering should be able to provide information about references (links) to other offerings.


4.1.6 COMMERCE AND LICENSING MANAGEMENT


4.1.6.1 Modules may have different payment schemes from different providers and for different users or group of users.
4.1.6.2 The system must enable transaction rules that enable and differentiate by affiliated, unaffiliated, and individual and group entities.
4.1.6.3 There will be a standard templates for charging/licensing models.
4.1.6.4 Containers can be offered from multiple entities each with their own transaction schedule.
4.1.6.5 Containers hold a reference to an entity that contains transaction schedules for that object.
4.1.6.6 The IMS specification will enable institutions and content providers to establish a set of site license agreements for modules. The hosting organization is responsible for maintaining its customer relationships and using that information within the IMS transaction process.


Columbia University purchases a site license for an American history offering from a content provider. Under the terms of the license, Columbia can make the offering available at no additional cost to any user of its IMS environment.


4.1.7 SECURITY MANAGEMENT


4.1.7.1 Enable single log-in.


4.1.8 TECHNICAL ADMINISTRATION MANAGEMENT


4.1.8.1 Develop a tool to automatically test for IMS compliance.
4.1.8.2 Develop a tool to test the compliance of gateways and ensure that data is exchanged between IMS environments and other systems effectively.


4.2 issues and approaches

As the development team of the IMS project began translating the IMS requirements into specifications and began implementing these specifications in the shape of a prototype, a number of issues arose. These issues will most likely need to be addressed by any developer of IMS materials and environments.  Therefore, we will identify some of the recurring issues or questions and possible strategies or rationale for addressing them.
general

The IMS Specification is being developed based on a conceptual object model. In order to support a distributed system of interoperable parts, the object model
provides the most flexibility and extensibility. Many existing systems, however,such as registrar systems, are not built on an object model. Therefore, the specification
will be sensitive to both the existing and evolving context and needs of online learning resources.

The IMS Specification is language independent. The IMS Prototype is being written primarily in Java. However, some utilities that enhance interoperability are being
developed in C++. In addition, the IMS Specification will include guidance and samples for utilizing IMS features in a pure HTML browser environment.

Any developer who uses the IMS Specifications for directing the development of learning resources can claim IMS-compliance. Certification of IMS-compliance,
however, is granted by an outside party. The National Institute of Standards and Technology (NIST)will identify the vendors who can provide certification services.

IMS member organizations have committed to the use and/or development of IMS-compliant products. In addition, the IMS project has a developers' network
program that continues to add more members interested in creating and servicing IMS-compliant tools, systems, and content. Some organizations, including those
not formally in the developer program, have already begun to use one aspect of the IMS specification by adding the appropriate IMS metadata to their learning
resources.
IMS INTERFACES

In order to begin addressing all the feature sets and their respective requirements (see previous chapter), the IMS technical development team has broken down the specification and prototype work into five inter-related parts represented by the diagram below.  These parts represent groups of interfaces and the resulting functionality that the specification will enable.

FIGURE 13:  INTEGRATED IMS INTERFACES

The feature sets used to organize the requirements in the preceding chapter do not map directly into the five interface categories of metadata, content, management, profiles, and external interfaces.  Rather, the implementation of different features is supported by various combinations of these interfaces. Each of these interfaces is discussed below and issues raised regarding their implementation.  This is not an exhaustive discussion of all the relevant issues, but merely highlights those issues that have been raised repeatedly by IMS partners, developers, and/or other interested parties.

4.2.1 Metadata


Description

Metadata is descriptive information about learning resources for the purpose of finding, managing, and using these resources more effectively.  The IMS metadata dictionary, currently available at http://www.imsproject.org/metadata/mddictionary.html, identifies the fields and their corresponding values necessary for creating IMS compliant resources.  
Issues

In order to be useful across a wide community of users, there needs to be a standard core vocabulary for the fields and values used to describe learning resources.  The IMS project metadata is derived from existing efforts to define these fields and values appropriately for educational materials.  In particular, the IMS metadata is based on the work from the Dublin Core metadata initiative.  The IMS project will continue to work with various organizations pursuing a metadata standard in order to create a common specification for learning resources.

Although standardization across terms is necessary for breadth of applicability, it is also important to allow individual communities to create descriptors that are specific and sensitive to the communities' unique needs.  Therefore, in order to be responsive to the changing needs of different user communities, the IMS project is working with the National Institute of Standards and Technology (NIST) to develop a process for autonomous use of metadata and also for the evolution of the core IMS metadata set.

As for development issues, one of the core objectives of the IMS project is to reduce the development time needed for creating learningware.  If adding the requisite metadata becomes too burdensome, then we have defeated this objective.  In order to facilitate the creation of metadata, a number of strategies have been employed.  First of all, several of the metadata values may be entered automatically by the users' system.  Secondly, when controlled vocabularies are used, the user may simply pick metadata values from a series of drop-down lists.  Finally, we are looking into the application of different tools for automating the creation of metadata (e.g. by storing templates of common values or by using an engine designed to scan the learning resources and determine the appropriate metadata).

4.2.2 "User Profile" \L3User Profile


Description

User profiles are mobile, user-controlled collections of personal and educational data (e.g. personal information, performance information, and preference information).  This data represents a rich resource that a user can draw on to facilitate, customize, and manage his or her learning experience(s).
Issues

User's maintain their own user profiles and have complete access and privileges to the information. It should be noted that performance information collected about a
student by an organization or school does not necessarily have to be stored in the IMS Profile. In this way, the organization can control the information it keeps on
the student. However, it is expected that organizations will place information traditionally found in a transcript into the user's IMS Profile. Utilizing digital signature
technology, the IMS Profile will protect against user's assigning themselves certifications for which they have not been certified.

The user profile will be accessible like a server. Programs will be able to access it, and you will be able to access it via a web browser. The records will be in
distributed databases. It is not the intent of the IMS to establish a single IMS Profile database. Our presumption is that there will be services offered by companies
and educational institutions that will host IMS Profiles for their customers and students.

Initially, a person will have a single IMS Profile. In future versions of the Specifications, the IMS Profile will support distribution and synchronization such that a
user's profile records may be spread across multiple IMS Profile servers. Future versions of the Specification will also detail the process of extending Profile
information.


4.2.3 "Content" \L3Content


Description

The IMS content interfaces define the actions and responses that IMS compliant content may perform.  These include functions such as assessment, reporting, sequencing, notification, bookmarking, activation, aggregation/diaggregation, simulation, and the basic message channel by which content communicates with other content and tools.
Issues

IMS content can be "created" with most any authoring tool that are on the market today. IMS-compliant courseware management system products will allow you,
without any programming involved, to group together education resources into sequences appropriate for students or employees.

In order to make existing content IMS compliant, a metaphorical IMS wrapper will be defined. For Web pages, you need to support IMS metadata tags in your
html code. IMS is working with the World Wide Web Consortium to finalize how to correctly represent IMS metadata tags according to an evolving metadata
infrastructure standard from W3. IMS will release Specifications for learning objects and CGI interfaces in the Jan-Feb time frame.


4.2.4 "Management" \L3Management


Description

The management interfaces form the skeleton of instructional management systems.  These functions include access control, session management, tracking students' progress, installation of learning resources, control over the virtual learning environment, storage/retrieval of learning contents, and security.
Issues

One can envision potential issues of scalability when examining the requirements for the amount of information tracked and transferred within and between IMS
environments. The management load will be dependent on a variety of factors including the amount of information generated by content, the type of information that
the instructor wishes to be tracked. Generally, the IMS management system that facilitates a student's learning process will store the information. However, an
instructor or the student may install additional utilities that store, analyze, and report the data for different purposes.

Many of the scalability issues for management systems are similar to those of any object-based system. The software industry is addressing these issues through
various proprietary and standards-based efforts. The emerging solutions will be drafted into the IMS Specification.


4.2.5 "External" \L3External


Description

External interfaces provide a means by which IMS compliant content and management software can leverage external systems that are likely to be found in an online learning environment.  These include electronic commerce, backoffice administrative systems, full-text indexing systems, digital library services, and other content or information databases.
Issues

Because organizations have already made large investments in administrative, commerce, and other systems, such as security, these services are being addressed
through external interfaces. IMS compliant content and management systems will communicate through interfaces to leverage these external infrastructures.

For example, security can be provided by an organization's existing security infrastructure, thus requiring users to login only to the network (and not requiring an
additional login to an IMS management system). In cases where an organization has little or no security, it is expected that IMS management system vendors will
include a security module that will provide login services within the context of their management system.


anno0

4 Self-evidentanno1
4
4.7.1.4.anno2
4
4.7.1.5.anno3
4
4.12.1.24.anno4
4
4.7.1.11.anno5
4
4.9.1.1.anno6
4
4.9.1.4.anno7
4
4.9.1.5.anno8
4
4.9.1.9.anno9
4
4.12.1.12anno10
4
4.12.1.25.anno11
4
4.12.1.5.anno12
4
4.4.1.3.anno13
4
4.12.1.6.anno14
4
4.12.1.7.anno15
4
4.12.1.11anno16
4
4.6.1.7.anno17
4
4.7.1.3.anno18
4
4.12.2.24.anno19
4
4.3.2.2.anno20
4
4.6.3.1.anno21
4
4.4.1.6.anno22
4
4.9.1.2.anno23
4
4.9.1.3.anno24
4
4.9.1.6.anno25
4
4.9.1.7.anno26
4
4.12.1.23.anno27
4
4.2.1.2.anno28
4
4.2.1.3.anno29
4
4.2.1.4.anno30
4
4.9.1.8.anno31
4
4.12.1.5.anno32
4
As all metadata is public, user data must be within the container.  User data is NOT metadata, as user can define access rights.  This requirement could be out of scope unless the IMS project is going to define a standard student record.  This means the IMS project will be defining a standard container's internal structure.  anno33
4
4.12.1.21.anno34
4
4.9.2.1.anno35
4
4.12.2.3.anno36
4
4.12.2.6.anno37
4
4.12.2.8.anno38
4
4.7.1.1.anno39
4
4.7.1.2.anno40
4
4.7.1.8.anno41
4
4.7.1.9.anno42
4
4.7.1.10anno43
4
4.8.1.1.anno44
4
4.2.1.6.anno45
4
4.4.1.4.anno46
4
4.2.1.5.anno47
4
4.7.1.6.anno48
4
4.7.1.7.anno49
4
4.7.2.1.anno50
4
4.3.1.1.anno51
4
4.3.1.2.anno52
4
4.3.1.3.anno53
4
4.3.1.4.anno54
4
4.3.1.5.anno55
4
4.13.1.1.anno56
4
4.3.2.1.anno57
4
4.3.2.3.anno58
4
4.3.3.1.anno59
4
4.12.1.26.anno60
4
4.15.1.7.anno61
4
4.6.1.6.anno62
4
4.6.1.8.anno63
4
4.6.1.9.anno64
4
4.6.1.5.anno65
4
4.15.1.2.anno66
4
4.1.1.7.anno67
4
4.15.1.4.anno68
4
4.5.1.2.anno69
4
4.10.1.3.anno70
4
4.10.1.2.anno71
4
4.5.1.1.anno72
4
4.5.1.3.anno73
4
4.15.1.1.anno74
4
4.15.1.3.anno75
4
4.5.1.4.anno76
4
4.12.1.2.anno77
4
4.15.1.8.anno78
4
4.12.1.3.anno79
4
4.12.1.22.anno80
4
4.6.1.1.anno81
4
4.6.1.2.anno82
4
4.6.1.3.anno83
4
4.6.1.4.anno84
4
4.15.1.4.anno85
4
4.5.2.1.anno86
4
4.5.2.2.anno87
4
4.10.2.1.anno88
4
4.12.2.2.anno89
4
4.12.2.7.anno90
4
4.15.2.3.anno91
4
4.8.1.6.anno92
4
4.8.1.7.anno93
4
4.5.1.5.anno94
4
4.5.1.6.anno95
4
4.14.1.14.anno96
4
4.14.1.6.anno97
4
4.8.1.2.anno98
4
4.15.1.5.anno99
4
4.15.1.6.anno100
4
4.12.1.9.anno101
4
4.14.1.11.anno102
4
4.12.1.13.anno103
4
4.14.1.1.anno104
4
4.14.1.7.anno105
4
4.14.1.12.anno106
4
4.14.1.16.anno107
4
4.14.1.2.anno108
4
4.14.1.3.anno109
4
4.14.1.5.anno110
4
4.14.1.4.anno111
4
4.14.1.8.anno112
4
4.14.1.9.anno113
4
4.14.1.10.anno114
4
4.14.1.15.anno115
4
4.14.2.1.anno116
4
4.14.2.2.anno117
4
4.14.2.3.anno118
4
4.14.2.4.anno119
4
4.14.3.1.anno120
4
4.14.3.2.anno121
4
4.2.1.1.anno122
4
4.4.1.1.anno123
4
4.4.1.5.anno124
4
4.4.1.7.anno125
4
4.4.1.8.anno126
4
4.12.1.8.anno127
4
4.4.1.2.anno128
4
4.12.1.17.anno129
4
4.12.1.1.anno130
4
4.4.2.1.anno131
4
4.1.1.1anno132
4
4.1.1.2anno133
4
4.8.1.3.anno134
4
4.8.1.4.anno135
4
4.8.1.5.anno136
4
4.1.1.3.anno137
4
4.1.1.4.anno138
4
4.11.1.1.anno139
4
4.11.1.4.anno140
4
4.1.1.5.anno141
4
4.1.1.6.anno142
4
4.1.1.8.anno143
4
4.1.1.9.anno144
4
4.11.1.2.anno145
4
4.11.1.3.anno146
4
4.12.1.14.anno147
4
4.12.1.15.anno148
4
4.12.1.16.anno149
4
4.12.1.18.anno150
4
4.12.1.19.anno151
4
4.12.1.20.anno152
4
4.15.2.1.



4

Document converted from word 8 by MSWordView (mswordview 0.4.4)
MSWordView written by Caolan McNamara