1EdTech Abstract Framework: Applications, Services, and Components

Version 1.0

Copyright © 2003 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech Abstract Framework: Applications, Services, and Components
Revision: 01 July 2003

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

1. Introduction
     1.1 Scope and Context
     1.2 Using this Document
     1.3 Structure of this Document
     1.4 Reference Documents
     1.5 List of Acronyms

2. Application Layer

3. Application Services Layer
     3.1 Assessment
     3.2 Calendar
     3.3 Class Administration
     3.4 Collaboration
     3.5 Commerce
     3.6 Competency Management
     3.7 Content Management
     3.8 Digital Repository Management
     3.9 Enterprise Service
     3.10 Group Management
     3.11 Learner Progression Management
     3.12 Membership Management
     3.13 Meta-data Management
     3.14 Party Management
     3.15 Portfolio Management
     3.16 Profile Management
     3.17 Sequencing
     3.18 Simulation

4. Common Services Layer
     4.1 Access Management
     4.2 Authentication
     4.3 Authorization
     4.4 Database Management
     4.5 Digital Rights Management
     4.6 Directory Service
     4.7 Discovery
     4.8 File Management
     4.9 Identification
     4.10 Querying
     4.11 Registry
     4.12 Relational Rules
     4.13 Scheduling
     4.14 Security and Privacy
     4.15 Subscription
     4.16 Tracking and Logging
     4.17 User Messaging
     4.18 Workflow

5. Sea of Components
     5.1 Accessibility
     5.2 Activity
     5.3 Affiliation
     5.4 Assessment
     5.5 Competency
     5.6 Content
     5.7 Course Catalogue
     5.8 Glossary
     5.9 Goal
     5.10 Grade-book
     5.11 Group
     5.12 Interest
     5.13 Item
     5.14 LOM
     5.15 Manifest
     5.16 Object-bank
     5.17 Outcomes Processing
     5.18 Party
     5.19 PLIRI
     5.20 Profile
     5.21 QCL
     5.22 Relationship
     5.23 Result Report
     5.24 Section
     5.25 SecurityKey
     5.26 Sequencing
     5.27 Syllabus
     5.28 Table of Contents
     5.29 Transcript

Appendix A - OKI APIs

About This Document

Revision History

Index

1. Introduction

1.1 Scope and Context

The 1EdTech Abstract Framework (IAF) is a device to enable the 1EdTech to describe the context within which it will continue to develop its eLearning technology specifications. This framework is not an attempt to define the 1EdTech architecture, rather it is a mechanism to define the set of services for which 1EdTech may or may not produce a set of interoperability specifications. In the cases where 1EdTech does not produce a specification then every effort will be made to adopt or recommend a suitable specification from another organization.

The IAF is a layered framework consisting of the Applications, Application Services, Common Services and Infrastructure layers. This document addresses the set of applications and services that are included within the scope of the Applications, Application Services and Common Services layers. The list of these applications and services is not exhaustive and as such it will be extended as and when new examples are identified.

1.2 Using this Document

This is a 'living' document i.e., it is not archival in nature. Our ideas for various parts of the IAF are constantly being developed and so the information contained herein should always be considered in that context. This document is one of a set of closely related documents, the others being:

The 1EdTech Abstract Framework: White Paper [1EdTech, 03a] - the definitions of the key terms used throughout the ALF and the associated specifications;
The 1EdTech Abstract Framework: Glossary [1EdTech, 03b] - the identification of the set of applications and services and their corresponding implementation components which can be used to support eLearning system interoperability (the separation of the detailed descriptions of the applications, services and components allows the details of this white paper to focus on the abstract representation itself);
The 1EdTech Learning Activity Model - the description of the underlying content model and the learner design mechanisms to be adopted for the provision of learning content (this document will not be available until mid 2004);
The 1EdTech Use Case Portfolio - the collection and collation of the core set of use cases that reflect the interoperability needs within eLearning systems (work on the collection of these use cases is underway);
The 1EdTech Specification Development Methods & Best Practices [1EdTech, 03c] - the identification of the methods and best practices that must be used when developing and documenting 1EdTech specifications.

The list of applications, services, and components in this document will be continually developed and as such they will form the basis of the specification development work programme to be undertaken. Not all of the services and components listed will undergo specification by 1EdTech.

1.3 Structure of this Document

The structure of this document is:


2. Application Layer	The brief description of some of the possible eLearning Applications;
3. Application Services Layer	The detailed description of the Application Services. This includes the definition of the different services including identification of the core application service components, interactions between the application services, interactions with the common services and the interactions with the applications layer;
4. Common Services Layer	The detailed description of the Common Services. This includes the definition of the different services including identification of the common components, interactions between the common services, interactions with the application services and the interactions with the infrastructure layer;
5. Components	The set of components that must be specified to support the identified set of application and common service;
Appendix A - OKI APIs	The set of APIs that have been developed under the Open Knowledge Initiative.

1.4 Reference Documents


[1EdTech, 03a]	1EdTech Abstract Framework: Glossary, K.Blinco, S.Griffin, J.Merriman, C.Smythe, 1EdTech Publication, Final Release, July 2003.
[1EdTech, 03b]	1EdTech Abstract Framework: White Paper, C.Smythe, 1EdTech Publication, Final Release, July 2003.
[1EdTech, 03c]	1EdTech Specification Development Methods & Best Practices, C.Smythe, 1EdTech Publication, Final Release, July 2003.
[SIF, 00]	Schools Interoperability Framework Implementation Specification, V1.0, Software & Information Industry Association, June 2000.
[SIF, 01]	Schools Interoperability Framework Draft Data Objects Specification, Draft, Software & Information Industry Association, December 2001.

1.5 List of Acronyms


API	Application Programming Interface
OKI	Open Knowledge Initiative
OSID	Open Service Interface Definition
SIF	Schools Interoperability Framework
IAF	1EdTech Abstract Framework
XML	Extensible Mark-up Language
PDF	Portable Document Format
LMS	Learning Management System
LCMS	Learning Content Management System
HTML	Hypertext Mark-up Language
OPAC	Online Public Access Catalogue
SIS	Student Information System

2. Application Layer

The entities in the application layer are a direct reflection of the eLearning domains. As such these domains are defined as:

Education - including schools, higher education, further education, community colleges
Corporate training - including professional certification, professional development, technology training, etc.

The intention is that the IAF can be adopted by different specification development organizations. As such this means that SIF will use it to support their work on specifications for K12, OKI for higher education, etc. Therefore, the applications listed below should be viewed as domain dependent, i.e., a K12 Assessment System will, in general, differ from a corporate training Assessment system but interoperability can be based upon the usage of the relevant profiled application services.

Only some of the applications available for eLearning applications are detailed below. The intention is not to create a definitive list but to identify a set of typical applications. The types of applications that could use the abstract framework application and common services are:

Assessment System - a computer-based application designed to evaluate a person's level of understanding of a particular content area. This may take the form of low-stakes (quizzes) and high-stakes (formal examinations) assessment;
Bulletin Board Tool - an application that enables information to be made available through an electronic notice-board. Many bulletin boards can be made available with each one focussing on a particular topic area. The tool provides access to the general users and the appointed moderator;
Content Authoring Tool - an application that supports the development of learning content. The nature of the authoring also includes support for native XML content and the creation of new content from the aggregation of reusable content;
Learning Content Management System - a computer application that enables the flexible management of content elements (such as text, graphics, animations, etc.) within a set of learning resources e.g, the individual resource files in a Content Package. In some cases, this may involve individual resources stored as XML described content which is dynamically rendered into alternative presentation formats, such as HTML, PDF, etc. The individual rendered files then make up the resources within the content package;
Learning Management System - a computer application that enables the assignment of content to learners, learning, and reporting of learning outcomes. The LMS is responsible for managing the learning activity and for reporting the outcomes to the appropriate support systems;
Library Management System - a computer application that manages the assets of a library throughout their lifecycle. An infoseeker typically discovers these assets through an interface known as the Online Public Access Catalogue (OPAC). The Library Management System may also provide digital asset management functions. Also, discovery and delivery services for assets located in remote repositories could be provided by this system or by a complement Information Resource System;
News Tool - an application tool that supports the development of news cast services;
Newsgroup Tools - an application tool that supports the creation and maintenance of email lists that allow groups of learners to exchange mutually useful information. Each newsgroup would normally focus on a particular topic or activity and membership and the information supplied would be subject to moderation;
Portal - an application that supports push and pull technologies for the collection, collation and distribution of information on a particular subject. The capabilities of the portal include the ability to categorize and search for information using a wide range of criteria;
Student Information System - a computer application that is a management information system for student information. Typically this system holds all of the information pertinent to the students learning within an organization. These systems exchange information with systems such as the LMS, LCMS, etc.

Note: 1EdTech will not undertake the specification of these applications. They are out-of-scope of the 1EdTech specification activity. Information concerning the types of applications is included to demonstrate how the set of application services and common services can be used.

3. Application Services Layer

Only some of the application services available for eLearning applications are detailed below. The intention is not to create a definitive list but to identify a set of core application services, such as:

Assessment - high and low stakes assessment provision;
Calendar - scheduling of events with respect to a calendar;
Class Administration - the management of classes;
Collaboration - support for interactions between two or more learners;
Commerce - services that support financial administration capabilities;
Competency Management - management of learner's competencies;
Content Management - management of learning content;
Digital Repository Management - management of digital repositories;
Enterprise Services - management of course enrolments and learning activities;
Group Management - the management of groups;
Learner Progression Management - management of a learner learning experiences;
Membership Management - the management of memberships in groups;
Meta-data Management - management of meta-data resources;
Party Management - the management of parties (people or organizations);
Portfolio Management - management of ePortfolios;
Profile Management - management of a learner's profile, life-long learning log, etc.
Sequencing - the sequencing of objects according to a set of sequencing rules;
Simulation - support for generic simulation services.

Note: In general, the specification of the Components to supply these Application Services will be the core 1EdTech specification activity. Also, an Application Service may or may not be an aggregation of other application services.

3.1 Assessment


Assessment
Service Description:	A service that is responsible for the presentation and reporting of an appropriate low-stakes/high stakes assessment. The assessment presentation and reporting is managed at the group and individual level.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Assessment Item Object-bank Section Result Report
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.2 Calendar


Calendar
Service Description:	A service that enables events to be sequenced as per their date. The calendar has a resolution covering hours to years.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Common Service Dependencies:	Scheduling
Infrastructure Dependencies:	TBD.

3.3 Class Administration


Class Administration
Service Description:	A service allowing educational applications to use and manage information regarding classes and people. In higher education implementations this service typically defines the interface between educational applications and student information systems.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Person Group Membership
Common Service Dependencies:	Scheduling
Infrastructure Dependencies:	TBD.

3.4 Collaboration


Collaboration
Service Description:	A service that enables two or more learners to work together through in an electronically mediated environment. Features include the provision of document sharing, white-boarding, application sharing, and videoconferencing.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.5 Commerce


Commerce
Service Description:	A service that provides financial administration information relevant to the eLearning system.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.6 Competency Management


Competency Management
Service Description:	A service that allows the management of the competencies-related aspects within an eLearning system. This includes the management of a learner's competencies, the creation of competency definitions and the association of these definitions within learner content, etc.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	RDCEO
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.7 Content Management


Content Management
Service Description:	A service that provides mechanisms for the creation, flexible management (e.g., aggregation, sequencing, dynamic rendering) and publishing of content. This service allows educational applications to publish, deliver, search for, and manage rights, role and meta-data information on digital assets.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Manifest
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.8 Digital Repository Management


Digital Repository Management
Service Description:	A service that enable access to, and the management, of a Repository. The repository may contain any type of content consistent with its function.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	LOM
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.9 Enterprise Service


Enterprise
Service Description:	A service that enables the management of learning activities that are based upon groups e.g., courses. This is an aggregation of other application services.
Service Access Points:	Party Service; Group Service; Membership Service.
Core Attributes:	TBD.
Core Components:	Party; Group; Membership.
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.10 Group Management


Group Management
Service Description:	A service that enables the management of Groups. A group can consists of other groups and may or may not have its own sub-groups.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Group
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.11 Learner Progression Management


Learner Progression Management
Service Description:	A service that is used to access and manipulate the information related to the progression of a learner through learning activities.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Profile
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.12 Membership Management


Membership Management
Service Description:	A service that enables the management of memberships. A party or group can be a member of a group. The membership information describes the role(s) that are undertaken as part of that membership.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Membership
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.13 Meta-data Management


Meta-data Management
Service Description:	A service that enable access to, and the manipulation of, the meta-data for a set of objects.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	LOM
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.14 Party Management


Party Management
Service Description:	A service that enables the management of a party. A party is either a person or an organization.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Party
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.15 Portfolio Management


Portfolio Management
Service Description:	A service that enables the management of ePortfolios.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.16 Profile Management


Profile Management
Service Description:	A service that enables access to, and the manipulation of a learner's profile. This service enables a single point of management access to a profile that may be replicated and or distributed in partial form across many Profile Repositories.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Profile
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.17 Sequencing


Sequencing
Service Description:	A service that enables any set of objects to be performed in any particular sequence. The set of possible sequences is defined using an appropriate set of sequencing rules.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	Sequencing
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

3.18 Simulation


Simulation
Service Description:	A service that enables real-time simulation of a system to be rendered through a generic interface. Any type of system can be simulated and so this service defines the set of permitted interactions to a particular simulation.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Common Service Dependencies:	TBD.
Infrastructure Dependencies:	TBD.

4. Common Services Layer

The following set of common services is not exhaustive, but is indicative of those that are to required by the different applications and application services (the set of OKI APIs that are available to support some of these common services are listed in Appendix A):

Access Management - the management of learner access to learning systems and resources;
Authentication - confirmation of the authenticity of an agent;
Authorization - authorization of an agent for a particular activity inc. authentication;
Database Management - access to local and remote databases inc. digital repositories;
Digital Rights Management - control over the usage of digital resources;
Directory Service - access to the information about network-accessible entities;
Discovery - the discovery of learning materials and other related information;
File Management - the storage and manipulation of static content;
Identification - locally and globally unique identifier allocation and manipulation;
Querying - the searching of repositories to retrieve objects conforming to the given set of criteria;
Registry - access to and manipulation of a registry;
Relational Rules - the creation and manipulation of sets of relationships;
Scheduling - the sequencing of activities according to a particular set of objectives;
Security & Privacy - the encryption of the end-to-end data stream;
Subscription - registration for a particular service;
Tracking & Logging - the tracking and logging of key events for any other service(s);
User Messaging - the synchronous/asynchronous exchange of messages between users;
Workflow - the automation of a particular document flow process.

Note: In general the 1EdTech will not undertake the specification of these services1. This is because they are generic in nature and as such are equally valuable in domains other than eLearning. Wherever possible 1EdTech will advocate the adoption of specifications for these services that have been developed by other activities e.g., OKI (the set of OKI APIs are listed in Appendix A).

4.1 Access Management


Access Management
Service Description:	A service that manages data about users, user profiles and services to access control systems so that authenticated users have access to those system, functions and resources that they are authorized to use. Single sign on, where the user is challenged for a single name and password and has access to more than one system or resource, functionality is also included.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.2 Authentication


Authentication
Service Description:	The authentication service gathers required credentials from an agent, vouches for their (the credentials) authenticity and introduces the agent to the system. The invoking application can determine and manipulate the authentication status of an agent without having to manage the details of a particular institution's environment. The service must work over various kinds of authentication infrastructure. Many institutions already have, or are striving for, central authentication. Examples of technologies in play include Kerberos, X.509 and cookie-based single sign-on technologies such as webISO. Increasingly institutions will be reaching beyond their traditional boundaries and operating in a universe of federated security domains, as for example with Shibboleth. Not only must the service handle different methods across the range of institutions, it must also handle these within a given institution. Some applications might rely on userid/password; some on certificates; most users authenticate locally; some might remotely. This range is represented in the interface using the concept of authentication type. There is typically a default type at an institution, the common method of authentication for the generality of use. Additional types are available to accommodate the rest. An agent, a human or inhuman principal, is authenticated according to one or more such types. There are, indeed, situations when an agent may need to be authenticated more than once in a session. This can happen when an agent switches from one type of activity to another. Checking the class schedule, for example, may require userid/password, while updating the final grades may require an X.509 certificate issued with a high level of assurance.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.3 Authorization


Authorization
Service Description:	A service that allows applications and application services to establish and query Authorizations. An Authorization has three components: the Agent that is authorized; the Function that the Agent is authorized to do; and the Qualifier representing the context in which the Agent can perform the Function.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.4 Database Management


Database Connectivity
Service Description:	A service that allows an application or application service to access and update the contents of a database. The intent of this service is to allow actual connection to the database to exist on a machine other than the machine hosting the application.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A reliable end-to-end communications system.

4.5 Digital Rights Management


Digital Rights Management
Service Description:	A service that provides mechanisms to enable permissions over learning object usage to be offered, controlled, tracked, and managed. The service also provides for the management of rights holders and their entitlements related to the usage of learning objects.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.6 Directory Service


Directory Service
Service Description:	A service that typically holds information about network-accessible entities such as services, other repositories, specifications, content objects, people and organizations, and provides a way of storing, manipulating and retrieving directory information that is both human and machine accessible. Information required by other services such as an authorization service or digital rights management service may be provided by a directory service.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	Optional usage of LDAP; Optional support for X.500.

4.7 Discovery


Identification
Service Description:	A service that enables the discovery of learning materials and other related information. Discovery is an action resulting from a query that involves presentation of results to the user. Querying typically depends on meta-data being exposed for effective discovery. Querying, browsing, 'following a path' are all a part of the discovery function.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	Optional usage of UDDI.

4.8 File Management


File Management
Service Description:	A service that provides a way of storing and retrieving static content. It provides an abstraction layer between the file system and the Application. This service may also provide automated recovery using multiple physical copies of a logical file.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	Should make usage of FTP; A trusted communications infrastructure for secure file access.

4.9 Identification


Identification
Service Description:	A service that is responsible for producing and making available Global/Local User Identifiers (GUIDs/LUIDs).
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	PLIRI
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.10 Querying


Querying
Service Description:	A service that permits a repository to be searched for objects that conform to a defined set of criteria. Querying is an operation performed typically by a user or agent wishing to discover and have information delivered from a system.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	Support for XML based and non-XML based querying and aggregation across a reliable communications system.

4.11 Registry


Registry
Service Description:	A service that enables access to, and the manipulation of, a registry. A registry typically holds meta-data schemas, configuration data, application profiles, identifiers or other lookup data that is both human and machine accessible.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A reliable end-to-end communications system.

4.12 Relational Rules


Relational Rules
Service Description:	A service that enables relationship rules to be established between objects. These rules are stored in an appropriate Rules Repository.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A reliable end-to-end communications system.

4.13 Scheduling


Scheduling
Service Description:	A service that enables a sequence of events to be tabled according to a particular calendar. This service enables activities from one or more sources to be coordinated using a single schedule.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A reliable end-to-end communications system.

4.14 Security and Privacy


Security and Privacy
Service Description:	A service that provides data encryption thereby making the information private and/or secure (the degree of depends on the cryptographic security of the encryption codes). This service may or may not be used in conjunction with other similar services supplied as a part of the Infrastructure Layer.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A reliable end-to-end communications system.

4.15 Subscription


Subscription
Service Description:	A service that provides the mechanism by which learners can subscribe to available services. This subscription may or may not include a financial transaction.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.16 Tracking and Logging


Tracking and Logging
Service Description:	A service that enables any other service to be tracked and the corresponding information and events to be logged. The log will be made available via a range of report formats. The tracking of a service enables all of the sequence of stable and meta-stable states to be recreated. The purpose of the Logging Service is to support logging throughout the system for diagnostic, performance: metrics, tuning, benchmarking, monitoring, security, performance, data collection, usage or trend analysis, forecasting, and statistics.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	A trusted communications infrastructure for the service.

4.17 User Messaging


User Messaging
Service Description:	A service that supports posting of instant or deferred and/or reliable messages from user to user, user to group, or system to user.
Service Access Points:	TBD.
Core Attributes:	TBD.
Core Components:	TBD.
Infrastructure Dependencies:	Based upon the Internet Protocol Suite messaging services: SMTP, POP3, and IMAP.

4.18 Workflow


Workflow
Service Description:	A service that supports the automation of the learning process. As such it allows a set of procedural rules to be defined and actioned across a number of actors and supporting systems.
Service Access Points:
Core Attributes:
Core Components:
Infrastructure Dependencies:

5. Sea of Components

The following set of components is not exhaustive, but is indicative of those that are to be developed by 1EdTech:

Accessibility - e-learning preferences;
Activity - e-learning products created by the learner;
Affiliation - the set of affiliations for an individual or organization;
Assessment - tests;
Competency - competencies and their relationships;
Content - the generic content model;
Course Catalogue - the set of courses available for study;
Glossary - keyword definitions for a particular usage;
Goal - the aspirations and targets fro a learner;
Grade-book - the scores allocated to a set of individuals;
Group - the collection of objects with a common purpose;
Interest - the interests of a learner;
Item - the question plus structure;
LOM - meta-data labels;
Manifest - the generic packaging component;
Object-bank - sets of Sections and/or Items;
Outcomes Processing - response processing for Assessments and Sections;
Party - individual and organization details;
PLIRI - the 1EdTech GUID;
Profile - a learner's profile record;
QCL - the qualifications, certifications and licenses for an individual or organization;
Relationship - the tuple relationship between the identified objects;
Result Report - results obtained from a test, quiz, etc.
Section - hierarchy structure for Assessments;
SecurityKey - generic security information;
Sequencing - the sequencing of content or any set of objects;
Syllabus - description of materials to be studied in some activity;
Table of Contents - list of contents in some package, document, etc.
Transcript - a summary record of performance;
Vocabulary - a set of terms defined for a particular usage.

5.1 Accessibility


Accessibility Component
Component Description:	An Accessibility Component contains the data structures and interfaces responsible for describing the cognitive, technical and physical preferences for the learner, disability, eligibility and language capabilities. These describe the learner's capabilities to interact with the learning environment.
Source Specification(s):	1EdTech LIP V1.0 (<accessibility>) 1EdTech Accessibility Guidelines V1.0 1EdTech ACCLIP V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

5.2 Activity


Activity Component
Component Description:	An Activity Component contains the data structures and interfaces responsible for describing the learning materials produced by the learner. This may consist of the education/training, work and service (military, community, voluntary, etc.) record and products (excluding formal awards). This information may include the descriptions of the courses undertaken and the records of the corresponding assessment.
Source Specification(s):	1EdTech LIP V1.0 (<activity>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Content Results Report Content Vocabulary PLIRI

5.3 Affiliation


Affiliation Component
Component Description:	An Affiliation Component contains the data structures and interfaces responsible for describing the organization affiliations associated with the learner e.g., professional memberships.
Source Specification(s):	1EdTech LIP (<affiliation>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.4 Assessment


Assessment Component
Component Description:	An Assessment Component contains all of the necessary instructions to enable the presentation of the associated Items, variable sequencing of the Items, the aggregated scoring for all of the Sections/Items to produce the final score(s), and the corresponding feedback. The Section Component is used to construct the appropriate hierarchical Section/Item groups. The results from an Assessment can be reported using the Result Report Component.
Source Specification(s):	1EdTech QTI V1.2 (<assessment>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Section Item Content Sequencing Outcomes Processing Vocabulary LOM PLIRI

5.5 Competency


Competency Component
Component Description:	A Competency Component contains the data structures and interfaces responsible for describing the skills the learner has acquired. These skills may be associated with some formal or informal training or work history (described in the 'activity') and formal awards (described in the QCL Component).
Source Specification(s):	1EdTech LIP V1.0 (<competency>) 1EdTech RDCEO V1.0 HR-XML Competency Definition
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.6 Content


Content Component
Component Description:	A Content Component contains the data structures and interfaces responsible for describing the logical structure, physical layout and associated presentation styles of the learning material. The material itself can take the form of text, image, video, audio, applet and an executable application. Alternative content issues are also addressed to support multi-lingual systems and to ensure the accessibility of the material.
Source Specification(s):	1EdTech QTI V1.2 1EdTech Learning Design V1.0 1EdTech Accessibility Guidelines V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	TBD.

5.7 Course Catalogue


Course Catalogue Component
Component Description:	A Course Catalogue Component contains the data structures and interfaces responsible for listing the set of courses available to a learner. The catalogue contains at least the title, identifiers, and the start/end dates of the course. Other information may also be made available depending on the type of catalogue.
Source Specification(s):	1EdTech Enterprise V1.1 (<group>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.8 Glossary


Glossary Component
Component Description:	A Glossary Component contains the data structures and interfaces responsible for defining a glossary of key words and phrases. It is possible to define different types of glossary and to have hierarchical glossaries.
Source Specification(s):	1EdTech Learning Design V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary

5.9 Goal


Goal Component
Component Description:	A Goal Component contains the data structures and interfaces responsible for describing the learner's personal objectives and aspirations. These descriptions may also include information for monitoring the progress in achieving the goals. A goal can be defined in terms of sub-goals.
Source Specification(s):	1EdTech LIP V1.0 (<goal>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI Content

5.10 Grade-book


Grade-book Component
Component Description:	A Grade-book Component contains the data structures and interfaces responsible for recording the grades, comments, attendance, and scores for a student or group.
Source Specification(s):	1EdTech Enterprise V1.1 (<group>) SIIA SIF
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI Result Report

5.11 Group


Group Component
Component Description:	The Group Component contains the data structures and interfaces responsible for describing a set of related objects. Each member of a group will be unique. The type of relationship is implicit in the type group.
Source Specification(s):	1EdTech Enterprise V1.1 (<group>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.12 Interest


Interest Component
Component Description:	An Interest Component contains the data structures and interfaces responsible for describing the hobbies and other recreational activities of a learner. These interests may have formal awards (as described in the associated 'QCL Component'). Electronic versions of the products of these interests may also be contained.
Source Specification(s):	1EdTech LIP V1.0 (<interest>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI Content

5.13 Item


Item Component
Component Description:	An Item Component contains all of the necessary instructions to enable the presentation of the associated question, the response processing to produce the set of scores, and the corresponding feedback. The results from an Item can be reported using the Result Report Component.
Source Specification(s):	1EdTech QTI V1.2 (<item>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Content Sequencing Outcomes Processing Vocabulary PLIRI

5.14 LOM


LOM Component
Component Description:	A LOM Component contains the data structures and interfaces responsible for labelling an associated resource. The way in which the meta-data is associated with the resource is established via the appropriate component definition.
Source Specification(s):	1EdTech Meta-data V1.2 IEEE LOM V1.0 MPEG7
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.15 Manifest


Manifest Component
Component Description:	A Manifest Component contains the data structures and interfaces responsible for constructing a content package. A content package is the 1EdTech's generic aggregation and packaging mechanism and as such it can be used to package any type of content.
Source Specification(s):	1EdTech Content Packaging V1.1 (<manifest>) MPEG21
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	LOM Vocabulary PLIRI Assessment Section Item Object-bank Profile Outcomes Processing Sequencing

5.16 Object-bank


Object-bank Component
Component Description:	The Object-bank Component is used to enable the grouping of Items and Sections in a data-bank. This data-bank is then used as the repository that is referenced by Assessments and Sections.
Source Specification(s):	1EdTech QTI V1.2 (<objectbank>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Item Section Assessment LOM PLIRI

5.17 Outcomes Processing


Outcomes Processing Component
Component Description:	An Outcome Processing Component contains the data structures and interfaces that provide the mechanism through which the scores from any combination of Item Components and Section Components can be combined using one of the predefined algorithms. The set of algorithms available for the aggregation are accessed through the outcomes processing component operators.
Source Specification(s):	1EdTech QTI V1.2
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	TBD.

5.18 Party


Party Component
Component Description:	The Party Component defines the data structures and interfaces responsible for describing an individual or an organization. The information includes names, addresses, demographics, agents, and contact information.
Source Specification(s):	1EdTech Enterprise V1.1 (<person>) 1EdTech LIP V1.0 (<identification>) vCard
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary PLIRI

5.19 PLIRI


PLIRI Component
Component Description:	The PLIRI Component defines the data structures and interfaces responsible for defining and allocating globally unique and locally unique identifiers.
Source Specification(s):	1EdTech LIP V1.0 1EdTech Enterprise V1.1 1EdTech Meta-data V1.2 IEEE LOM V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	TBD.

5.20 Profile


Profile Component
Component Description:	The Profile Component defines the data structures and interfaces responsible for constructing and manipulating a learner's profile. The profile may vary from a detailed life long learning log to a short summary of personal details. A learner may have more than one profile and each profile may be distributed across several profile servers.
Source Specification(s):	1EdTech LIP (<learnerinformation>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Person Accessibility Affiliation Activity Goal QCL Competency Interest Relationship SecurityKey Transcript

5.21 QCL


QCL Component
Component Description:	A QCL Component defines the data structures and interfaces responsible for describing the qualifications, certifications and licenses awarded to the learner i.e., the formally recognized products of their learning and work history. This includes information on the awarding body and may also include electronic copies of the actual documents.
Source Specification(s):	1EdTech LIP V1.0 (<qcl>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary Content

5.22 Relationship


Relationship Component
Component Description:	A Relationship Component defines the data structures and interfaces responsible defining the relations between other Components. All of the relationship information has been removed from the other components to enable these to be manipulated using a single independent component. The relationship is defined using a particular vocabulary and the components are identified using the appropriate PLIRI.
Source Specification(s):	1EdTech LIP V1.0 (<relationship>) OKI APIs
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

5.23 Result Report


Result Report Component
Component Description:	The Result Report Component is used to report the results from any form of assessment e.g., a Test, Quiz, etc. The assessment may or may not be based upon the Assessment, Section or Item Components. Any level of detail can be reported from the assessment with the exception of tracking level information.
Source Specification(s):	1EdTech QTI V1.2
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	LOM PLIRI

5.24 Section


Section Component
Component Description:	A Section Component contains all of the necessary instructions to enable the presentation of the associated Items, variable sequencing of the Sections/Items, the aggregated scoring for all of the Items to produce the Section score(s), and the corresponding feedback. The Section is used to construct hierarchical Section/Item groups The results from a Section can be reported using the Result Report Component.
Source Specification(s):	1EdTech QTI V1.2 (<section>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Item Content Sequencing Outcomes Processing Vocabulary LOM PLIRI

5.25 SecurityKey


SecurityKey Component
Component Description:	The SecurityKey Component defines the data structures and interfaces responsible for storing the passwords and security codes that are to be used when communicating with the learner.
Source Specification(s):	1EdTech LIP V1.0 (<securitykey>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

5.26 Sequencing


Sequencing Component
Component Description:	A Sequencing Component defines the data structures and interfaces responsible for describing the set of possible presentation sequences for the collection of content resources.
Source Specification(s):	1EdTech QTI V1.2 1EdTech Simple Sequencing V1.0 1EdTech Learning Design V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	Vocabulary

5.27 Syllabus


Syllabus Component
Component Description:	A Syllabus Component defines the data structures and interfaces responsible for representing the syllabus for a course.
Source Specification(s):	1EdTech Learning Design V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

5.28 Table of Contents


Table of Contents Component
Component Description:	A Table of Contents Component defines the data structures and interfaces responsible for representing the table of contents of a list of related objects e.g., a content package.
Source Specification(s):	1EdTech Learning Design V1.0
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

5.29 Transcript


Transcript Component
Component Description:	A Transcript Component contains the data structures and interfaces responsible for describing a learner's transcript i.e., the summary records of the academic performance at an institution. This information may contain an arbitrary level of detail and so there is no proscribed structure for a transcript. This component contains no layout information for the transcript.
Source Specification(s):	1EdTech LIP (<transcript>)
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	PLIRI Vocabulary

6.30. Vocabulary


Vocabulary Component
Component Description:	A Vocabulary Component contains the data structures and interfaces for representing a vocabulary. This vocabulary may be constructed as a simple list or a complex taxonomy.
Source Specification(s):	1EdTech LIP V1.0 1EdTech Meta-data V1.2 IEEE LOM V1.0 1EdTech QTI V1.2 1EdTech Enterprise V1.1
Interfaces:	TBD.
Core Attributes:	TBD.
Protocol Requirements:	TBD.
Component Dependencies:	TBD.

Appendix A - OKI APIs

The deliverables from the OKI are the two sets of Java APIs for the Common Services and the Educational Services. The set of Java APIs for the Common Services are listed in Table A1.

Table A1 - List of OKI Java APIs for Common Services.


API Title	Description
Authentication	The Authentication OSID gathers required credentials from an agent, vouches for their authenticity and introduces the agent to the system This service permits an application to abstract the authentication process without having to manage the details of the underlying authentication service.
Authorization	The Authorization OSID allows an application to establish and query a user's privileges to view, create, or modify application data, or use application functionality. Applications that can change Enterprise data need to manage a user's access to that data. An application must provide a fine degree of authorization granularity to reflect the complexity of a user's interaction with an application
Database Control	The DBC OSID allows an application to access and modify the contents of a database by using the java.sql and javax.sql packages. What differentiates the DBC OSID from JDBC is that by extending java.io.Serializable this OSID's objects can migrate across machine boundaries, permitting the database connection to exist on a machine other than the machine hosting the application.
SQL	The SQL OSID provides relational database access functionality at a higher level of abstraction than the DBC OSID. Unlike DBC, it is not dependent on JDBC. An application's access to persistent information should focus on its own data manipulation requirements, not the operational details of the underlying data provider.
Logging	The Logging OSID records and retrieves a variety of application activity history. Applications typically track a variety of internal events and activity for purposes of analysis, data collection, and security.
Shared	The Shared OSID contains fundamental objects used in the other OSIDs to provide their functionality. The contents of the Shared OSID are used throughout O.K.I.-compliant implementations and applications
Filing	The Filing OSID provides platform-independent means to handle files arranged in simple hierarchical containers. Most applications have occasion to manipulate their data through the use of files in some sort of file system.
Hierarchy	The Hierarchy OSID manages parent-child relationships among elements. In addition to simple tree structures, the OSID supports hierarchies that are recursive and have nodes with multiple parents. Parent-child relationships are fundamental structures that effectively model a variety of enterprise data.
User Messaging	The Usermessaging OSID supports communication and notification among users. Person to person (P2P) messaging has become a useful application feature with the availability of supporting P2P services as well as e-mail, instant chat, and discussion boards.
Dictionary	The Dictionary OSID provides a means to support multiple languages, domain-specific nomenclature and culture-specific conventions through interchangeable property files. Applications that can operate in a variety of cultural settings offer more value to a broader user community.
Scheduling	The Scheduling OSID manages events in shared calendars. Class schedules are an example of events that are managed in shared calendars.
Workflow	The Workflow OSID provides a way to manage an interdependent succession of activities each of which has completion constraints. Certain types of applications have operations where one action is dependent on the completion of a previous action.

About This Document


Title	The 1EdTech Abstract Framework: Applications, Services, and Components
Authors	Colin Smythe (1EdTech)
Version	1.0
Version Date	01 July 2003
Status	Final
Summary	This document details the current list of applications, application services, common services and components that can be supplied within the context of the 1EdTech Abstract Framework.
Revision Information	01 July 2003
Purpose	This is document is a part of the 1EdTech Abstract Framework and as such should be considered as a reference text for the 1EdTech specifications.
Document Location	http://www.imsglobal.org/af/index.cfm

List of Contributors

The individuals who contributed to the development of this white paper are:


Thor Anderson	Collegis, USA
Bill Blackmon	Carnegie Mellon University, USA
Giorgio Da Bormida	Giunti Interactive Labs, Italy
Kerry Blinko	DEST, Australia
Chris Etesse	Blackboard, USA
Michael J.Halm	CIC/PSU USA
Dirk Herr-Hoyman	University of Wisconsin, USA
Ralph LeVan	OCLC, USA
Tim Magner	SIIA, USA
Jon Mason	DEST, Australia
Jeff Merriman	MIT, USA
Mark Norton	1EdTech, USA
Dan Rehak	Carnegie Mellon University, USA
Kevin Riley	1EdTech, USA
Stuart Sim	SUN, UK
Colin Smythe	1EdTech, UK
Scott Thorne	MIT, USA
Michael Vax	WebCT, USA
Chris Vento	WebCT, USA
Ed Walker	1EdTech, USA

Revision History


Version No.	Release Date	Comments
Final 1.0	01 July 2003	The first formal release of the 1EdTech Abstract Framework Applications, Services & Components.

Index

A
Access 1, 2, 3
Access Management 1
Accessibility 1, 2, 3, 4
Accessibility Component 1
Activity Component 1
Affiliation Component 1
Agent 1
API 1, 2
Application 1, 2, 3, 4, 5, 6
Application Layer 1, 2
Application Service 1, 2, 3
Application Services
     Assessment 1, 2, 3, 4, 5, 6
     Calendar 1, 2
     Class Administration 1, 2
     Collaboration 1, 2
     Commerce 1, 2
     Competency Management 1, 2
     Content Management 1, 2
     Digital Repository Management 1, 2
     Enterprise Service 1, 2
     Group Management 1, 2
     Learner Progression Management 1, 2
     Membership Management 1, 2
     Meta-data Management 1, 2
     Portfolio Management 1, 2
     Sequencing 1, 2, 3, 4, 5, 6, 7, 8
     Simulation 1, 2
Application Services Layer 1, 2
Assessment 1, 2, 3, 4, 5, 6
Assessment Component 1
Assessment System 1
Authentication 1, 2, 3
Authorization 1, 2, 3

C
Class 1, 2, 3
Common Service 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Common Services
     Access Management 1
     Authentication 1, 2, 3
     Authorization 1, 2, 3
     Database Management 1, 2
     Digital Rights Management 1, 2
     Directory Service 1, 2
     Discovery 1, 2
     File Management 1, 2
     Identification 1, 2, 3
     Querying 1, 2, 3
     Registry 1, 2
     Scheduling 1, 2, 3, 4
     Security & Privacy 1, 2
     Subscription 1, 2
     Tracking & Logging 1, 2
     User Messaging 1, 2, 3
     Workflow 1, 2, 3
Common Services Layer 1, 2
Component 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Components
     Accessibility 1
     Activity 1
     Assessment 1
     Goal 1
     Grade-book 1
     Group 1
     Item 1, 2, 3
     Manifest 1
     Object-bank 1
     QCL 1, 2, 3
     Relationship 1
     Section 1, 2, 3
     Sequencing 1
     Transcript 1
     Vocabulary 1
Content Package 1
Course Catalogue 1, 2
Course Catalogue Component 1

D
Digital Repository 1, 2
Digital Rights Management 1, 2
Directory 1, 2

F
Framework 1, 2, 3, 4
FTP 1

G
Goal Component 1
Grade-book 1, 2
Grade-book Component 1
Group Component 1
Group Management 1, 2

H
HR-XML 1

I
IEEE
     API 1, 2
     Authentication 1, 2, 3
     Authorization 1, 2, 3
     IEEE 1, 2, 3
     LOM 1, 2, 3, 4, 5, 6, 7, 8, 9
IETF
     FTP 1
     Internet Protocol 1
     LDAP 1
     SMTP 1
     vCard 1
Implementation 1
Infrastructure 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Infrastructure Layer 1
Interest Component 1
Interface 1
Internet Protocol 1
Item 1, 2, 3, 4, 5, 6, 7, 8
Item Component 1, 2, 3

L
Layers
     Application Services 1, 2
     Common Services 1, 2
     Infrastructure 1
LCMS 1, 2
LDAP 1
Learner 1, 2
Learning Content Management System 1, 2
Learning Management 1, 2
Learning Management System 1, 2
LOM 1, 2, 3, 4, 5, 6, 7, 8, 9

M
Manifest 1, 2, 3
Manifest Component 1
Membership 1, 2, 3, 4
Meta-data 1, 2, 3, 4, 5

O
Object-bank 1, 2, 3
Object-bank Component 1
OKI
     Application Service 1, 2, 3
     Common Service 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     OKI 1, 2, 3, 4, 5
     Open Knowledge Initiative 1
Open Knowledge Initiative 1
Outcomes Processing 1, 2, 3, 4, 5, 6
Outcomes Processing Component 1

P
Pearty Component 1
Portfolio Management 1, 2
Profile Management 1, 2

R
Registry 1, 2
Relationship Component 1
Repository 1, 2
Resource 1

S
Schools Interoperability Framework 1
Section 1, 2, 3, 4, 5, 6, 7
Section Component 1, 2, 3
Security 1, 2
Securitykey Component 1
Sequencing Component 1
Service 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
Service Access Point 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Services
Application

Assessment 1, 2, 3, 4, 5, 6

Calendar 1, 2

Class Administration 1, 2

Collaboration 1, 2

Commerce 1, 2

Competency Management 1, 2

Content Management 1, 2

Digital Repository Management 1, 2

Enterprise Service 1, 2

Group Management 1, 2

Learner Progression Management 1, 2

Membership Management 1, 2

Meta-data Management 1, 2

Portfolio Management 1, 2

Sequencing 1, 2, 3, 4, 5, 6, 7, 8

Simulation 1, 2 Common

Access Management 1

Authentication 1, 2, 3

Authorization 1, 2, 3

Database Management 1, 2

Digital Rights Management 1, 2

Directory Service 1, 2

Discovery 1, 2

File Management 1, 2

Identification 1, 2, 3

Querying 1, 2, 3

Registry 1, 2

Scheduling 1, 2, 3, 4

Security & Privacy 1, 2

Subscription 1, 2

Tracking & Logging 1, 2

User Messaging 1, 2, 3

Workflow 1, 2, 3 SIF
Schools Interoperability Framework 1
SIF 1, 2, 3
Simple Sequencing 1
SMTP 1
Student Information System 1, 2

T
Tracking 1, 2
Transcript 1, 2, 3
Transcript Component 1

U
UML
     Class 1, 2, 3
     Component 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     Use-case 1
Use-case 1
Use-case Portfolio 1
User 1, 2, 3, 4

V
vCard 1
Vocabulary 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13

W
W3C
XML 1, 2, 3

X
XML 1, 2, 3

Although new common service specifications will not be undertaken by 1EdTech the identification of appropriate common services will be supported. An example of this is the IAF Common Services development activity that will be undertaken in late 2003. This activity will be responsible for documenting and describing the best practices to be adopted when using a predefined set of Common Services. These Common Services will be taken from other specification sources e.g., OKI, and so the 1EdTech will be showing how the OKI APIs can be used with 1EdTech Application Services.

1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Abstract Framework: Applications, Services, and Components ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at http://www.imsglobal.org

Please refer to Document Name: 1EdTech Abstract Framework: Applications, Services, and Components Revision: 01 July 2003