 |
1EdTech Reusable Definition of Competency or Educational Objective - Best Practice and Implementation Guide Version 1.0 Final Specification |
Copyright © 2002 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech Reusable Definition of Competency or Educational Objective - Best Practice and Implementation Guide
Revision: 25 October 2002
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.
Copyright © 2002 1EdTech Consortium. All Rights Reserved.
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.
Table of Contents
1. Introduction
1.1 Overview
1.2 Scope and Context
1.3 Requirements
1.4 Structure of this Document
1.5 Nomenclature
1.6 References
2. RDCEO Conceptual Model
2.1 Scope
2.2 Persistence
2.3 Applications
2.3.1 Taxonomies, Maps, and Skill-Gap Analysis
2.3.2 Courses, Learning Objects, Resource Discovery, and Educational Objective
3. Relation to Other Specifications
3.1 Within the Framework of 1EdTech Specifications
3.1.1 1EdTech Guidelines for Globally Unique Identifiers
3.1.2 LOM (and 1EdTech Meta-Data) as Used in a RDCEO Instance
3.1.3 Reference to a RDCEO in LOM (and 1EdTech Meta-Data)
3.1.4 Learner Information Packaging (LIP) Information Model
3.1.5 Bundling Using Content Packaging
3.1.6 Simple Sequencing
3.2 Related Specifications
3.2.1 IEEE LOM
3.2.2 HR-XML Competencies
4. Implementation Guidance
4.1 Using the RDCEO Data Structures
4.1.1 <rdceo>
4.1.2 RDCEO Identifiers
4.1.3 <title> and <description>
4.1.4 <definition>
4.1.5 <metadata>
4.2 Distributed Architectures and Considerations
5. Basic examples of RDCEO instances
5.1 Minimal Example
5.2 Use of URN for Identifier
5.3 A Made-Up Example of a Competency in Reading 1EdTech Specifications
5.4 A Core Competency for CPAs
5.5 A High School Competency (Outcome) from (NOICC)
5.6 A Proficiency for Admissions to College in Oregon (PASS)
5.7 A Conformance Statement for SCORM Compliance Phrased as a Competency Definition
5.8 Example Using 1EdTech Meta-Data in RDCEO Instance
6. Application examples
6.1 1EdTech Meta-Data v1.2
6.2 IEEE LOM
6.3 HR-XML Competencies 1.0
6.4 1EdTech Learner Information Package
6.4.1 Learner Competency Data
6.4.2 Learner Goal Record (with Local Definition of Educational Objective)
6.5 1EdTech Simple Sequencing
6.6 Fictional Examples
6.6.1 A Competency Certificate
6.6.2 A List of Desired Competencies Resulting from Skill-Gap Analysis
6.6.3 A Skills Hierarchy
6.6.4 A Hiearchical Tree of Learning Objectives
6.6.5 A Fragment of a Complex Map of Related Competencies
Appendix A - Case Study, UK Learning and Skills Development Agency (LSDA)
A1 - Requirement Statement
A2 - What the Framework Is
A3 - What the Framework Can Do
Appendix B - Future Work
About This Document
List of Contributors
Revision History
1. Introduction
1.1 Overview
This specification defines an information model for describing, referencing, and exchanging definitions of competencies, primarily in the context of online and distributed learning. In this specification, the word competency is used in a very general sense that includes skills, knowledge, tasks, and learning outcomes. This specification gives a way to formally represent the key characteristics of a competency, independent of its use in any particular context. It enables interoperability among learning systems that deal with competency information by providing a means for them to refer to common definitions with common meanings.
The core information in a Reusable Definition of Competency or Educational Objective (RDCEO) is an unstructured textual definition of the competency that can be referenced through a globally unique identifier. This information may be refined using a user-defined model of the structure of a competency.
The RDCEO specification provides a means to create common understandings of competencies that appear as part of a learning or career plan, as learning pre-requisites, or as learning outcomes. The information model in this specification can be used to exchange these definitions between learning systems, human resource systems, learning content, competency or skills repositories, and other relevant systems. RDCEO provides unique references to descriptions of competencies or objectives for inclusion in other information models.
The RDCEO that conform to this specification are intended for interchange by machines, but the information they contain is currently intended for human interpretation. This specification does not address the aggregation of smaller competencies into larger competencies (e.g., "throws" plus "catches" equals "plays ball") and does not address how competencies are to be assessed, certified, recorded, or used as part of a process such as instructional design or knowledge management. It also does not specify how records of competencies associated with an individual are structured, stored, or exchanged.
1.2 Scope and Context
This document is the 1EdTech Reusable Definition of Competency and Educational Objective Specification version 1.0. As such it forms one of a set that comprise the specification, each with distinct scope:
Describes the core aspects of the specification and is normative for any binding claiming to use this information model. It contains details of: semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whether mandatory or optional).
Describes a binding of the Information Model to XML version 1.0 and is normative for any XML instance that claims to use this binding, whether by reference to the specification or by declaration of the namespace reserved by the specification. In cases of error or omission, the Information Model takes precedence. The RDCEO XML Binding is released with a control document using W3C Schema Language that should be used in implementations.
Best Practice and Implementation Guide
Provides non-normative guidance on application of the Information Model and XML Binding. This includes reference to existing practice in handling information that this specification seeks to support and guidance on practices that will promote interoperability and durability. It also includes examples to illustrate how the conceptual framework maps to practical uses and to identify the relationship between this specification and related 1EdTech specifications. Implementers are encouraged, but not required, to follow guidance in this part of the specification.
1.3 Requirements
The requirements for a specification to allow exchange of definitions of competency and educational objective come from diverse areas of e-learning and human resource management (HRM). The specific value in a common form to exchange objective data may be derived from the requirements, scenarios, and use cases that supported the development of specifications such as 1EdTech Learner Information Packaging and HR-XML Competencies.
Because the 1EdTech Reusable Definition of Competency and Educational Objective specification is designed to support applications rather than be particularly useful on its own, we will refer the reader to:
- Other specifications, section 3;
- Applications to illustrate the RDCEO conceptual model, section 2.3
- A case study, appendix A.
In addition to these application-domain requirements, all 1EdTech specifications are produced subject to the requirements that any 1EdTech interoperability specification be:
- Bindable to XML for exchange;
- Workable in a distributed data paradigm;
- Usable in systems that need to scale and perform;
- Flexible to a range of applications;
- Practically implementable;
- Of a clearly defined purpose.
1.4 Structure of this Document
The structure of this document is:
1.5 Nomenclature
1.6 References
| (ACRL) | http://www.ala.org/acrl/ilstandardlo.html (Association of College and Research Libraries. Information Literacy Competency Standards for Higher Education: Standards, Performance Indicators, and Outcomes) |
| (CASAS) | http://www.casas.org/ |
| (CPA) | http://www.cpavision.org/poll/corecomp.cfm (Core Competencies for CPAs) |
| (HR-XML) | http://www.hr-xml.org/ (HR-XML Consortium) |
| (IEEE LOM) | http://ltsc.ieee.org (IEEE 1484-12:2002, Standard for Learning Object Metadata) |
| (IMSBUND) | http://www.imsglobal.org/implementationhandbook/imspack_handv1p0.html (Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications) |
| (IMSMD) | http://www.imsglobal.org/metadata/ (1EdTech Meta-Data Specification) |
| (IMSPLID) | http://www.imsglobal.org/implementationhandbook/imsrid_handv1p0.html, 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0 |
| (LSDA) | http://www.lsda.org.uk/ (Learning and Skills Development Agency) |
| (Mager) | Robert Mager, 1984. Preparing Instructional Objectives, 2nd Edition. Lake Pub. Co., Belmont, CA. |
| (NOCN) | http://www.nocn.org.uk/ (National Open College Network) |
| (NOICC) | http://www.academicinnovations.com/noicc.html (National Occupational Information Coordinating Committee: High School Student Competencies and Indicators) |
| (O*NET) | http://online.onetcenter.org/ (or http://www.access.gpo.gov/o_net/datadict/datadict.pdf) |
| (Ostyn) | http://ltsc.ieee.org/doc/wg20/CompDefInit.doc (Base document from P1484.20) |
| (PASS) | http://www.ous.edu/pass/standards/admission.html (Oregon Proficiency-based Admissions Standards System) |
| (RFC 2396) | http://www.ietf.org/rfc/rfc2396.txt (Uniform Resource Identifiers. Section 4 of this document defines URL Reference) |
| (SCANS) | http://www.tier.net/tcenters/scans.htm (Secretary's Commission on Achieving Necessary Skills: Competencies) |
| (SCORM) | http://www.adlnet.org (ADL SCORM) |
| (TATS) | http://www.adtdl.army.mil/atdls.htm (Total Army Training System) |
| (XPOINTER) | http://www.w3.org/TR/xptr-framework/ (XPointer Framework, Working Draft 10 July 2002) |
2. RDCEO Conceptual Model
The RDCEO data model is minimalist and extensible. It is purposely neutral with regard to models of competencies and the use of competencies.
Note: The word competencies here is to be interpreted in the most broad sense to include educational objectives (those things that are sought) and competency (those things that are achieved). The word "competency" is also used to include all classes of things that someone, or potentially something, can be competent in, although some communities of practice use the word with nuance, for example limiting its use to skill and excluding knowledge or understanding.
Competencies are defined and structured in many ways in different communities of practice (ACRL, CASAS, CPA, LSDA, Mager, NOCN, NOICC, O*Net, PASS, SCANS, TATS). This list is clearly not complete. Although it is international in scope, it does not reflect all the diverse communities of practice even within one nation - a fact of life that this specification must, and can, service. This specification allows communities of practice to exchange information according to the model they use. It is strictly limited to defining competency or educational objective; data relating to individuals does not form part of a RDCEO but may appear in an 1EdTech Learner Information Package, for example.
The Information Model document describes the elements of the RDCEO data model and this document provides context and current best practice in its application.
2.1 Scope
The RDCEO specification addresses a small but productive segment of the entire problem space for competency standards. It deals only with data rather than specifying how the data should be used.
Within the Competency data space, the RDCEO specification focuses only on an information model to exchange competency data that can be reused for more than one person, in more than one context, and with different dimensions. Other standard activities have and will focus on those other aspects. For example, how to exchange information about the evidence of competency is out of scope for this specification.
There are various ways to classify competencies. This specification is intended to meet the simple need of referencing a competency, not classifying it. Nonetheless, an implementation might want to include classifications, which can be done through the optional meta-data mechanism.
2.2 Persistence
Much of the value of RDCEOs lies in the fact that they can be referenced. To realize this value, it is important that RDCEOs be persistent and stable, and identified by globally unique identifiers. In fact, once a competency definition with such an identifier has been published it should never be modified again. This is similar to a book. Once published, you cannot "unpublish" it. You can make new editions and revisions, of course, but those are in effect known as new editions and not confused with the original. The same applies to published RDCEOs: if updates or modifications are necessary, a new instance of the RDCEO must be created, with a new and different identification. This new instance may contain data that points to the old version.
It is expected that repositories for RDCEOs will be established and that some of those repositories will be publicly accessible, or accessible to trading partners. Because each particular definition has a unique identifier and is immutable, definitions can be replicated across repositories with full confidence. Such repositories do exist in fact as of this writing in 2002, but they cannot exchange information in a standard way because they all use different information models or assumptions. The practices used in these repositories have informed the development of the RDCEO specification. When RDCEO definitions are stored in repositories, anyone who needs to look up the content of a definition can simply look it up through its unique identifier. The application examples below show how collecting and exchanging just the identifiers is practical and economical for many processing tasks that involve competency management.
2.3 Applications
This section describes some of the ways in which the RDCEO specification may be employed. It is indicative only and meant to assist readers in understanding how the RDCEO specification could be applied to their community or market; innovation should prevail. Further information on application in relation to 1EdTech and others specifications may be found in section 3, Relation to Other Specifications, in the specifications mentioned in this section, and in section 6, Application Examples.
2.3.1 Taxonomies, Maps, and Skill-Gap Analysis
One example of the use of competency definitions may be as building blocks in competency taxonomies or maps. In fact, such a taxonomy or map may be little more than an organized collection of references to RDCEOs.
Another typical example of the use of RDCEOs is in skill-gap analysis. Learner competency records, which typically contain information about evidence of competency (or the lack thereof) coupled with a reference to a competency definition. The competency definitions are also referenced by a competency model. By matching this information, it is possible to generate a collection of competency definition references. This collection identifies the skills for which there is no evidence of mastery in the learner's record. By using RDCEOs, and references to those definitions, the amount of data that must be stored and processed to record and manage competency information can be reduced dramatically.
The same conceptual process may be applied to adaptive and personalized learning systems using either procedural logic or knowledge-based approaches. Indeed, the importance of what a learner can do in driving such processes rather than what the learner has done (specific learning experiences) is crucial to this process.
2.3.2 Courses, Learning Objects, Resource Discovery, and Educational Objective
The centrality of an educational objective as what distinguishes a learning resource from any other kind of resource is critical when dealing with learning objects in the broad sense of anything from a raw asset to a course. This makes a strong statement about the process of devising chunks of learning - that educators or instructional designers are expected to explicitly define learning outcomes for any chunk of learning (of sufficient size) which they produce. This is particularly the case if the chunk is going to be available for reuse. It is irrespective of whether these outcomes are going to be formally assessed or not. However, if assessment is happening, then the opportunity exists to record that the learner has achieved a learning outcome.
Also, since the hope is that reusable chunks of learning will be reasonably fine-grained, the implication is that some learning outcomes will also be fine-grained, covering one small, detailed learning outcome. (Although they can be aggregated up into courser-grained learning outcomes.)
- An educator in developing a new course first defines the learning outcomes the course should deliver, then searches for or develops:
- A tutor or learner uses learning outcomes to search for appropriate resources in a repository, in order to build up a learning program.
- In figuring out what course a learner wishes to enrol in, a learner and his/her adviser primarily think about learning outcomes the learner wishes to achieve, and they match these to the learning outcomes of the modules / courses/ learning programs being offered. (Possibly using learning needs assessments which help identify the learning outcomes / competencies which the learner possesses and lacks.)
- Achievement of learning outcomes may be recorded as the learner progresses through the course, and used by both learner and tutor to reflect on the learner's progress.
In general there are two (complementary) approaches to cataloging, and hence locating resources:
- Using an agreed classification scheme, and a controlled vocabulary. Two advantages of this approach are:
- Access to the classification categories can help users in their search. For example, if I'm interested in taking a course in Social Care, the system can show me what sub-categories the institution has defined, so I can drill down to Child Care, and then to Nursery Education. This can be more helpful than being presented with a blank search box, and having to think up appropriate query words to enter.
- A controlled vocabulary avoids the situation where (for example) some courses are classified under "care of the elderly" and some under "care of old people", so that users typing in either "elderly" or "old people" only retrieve half the relevant courses.
- Using free text. Three advantages of this approach are:
Both approaches are relevant to resource discovery using learning outcomes to extend the existing availability of subject-based classification such as Dewey Decimal or Universal Decimal.
3. Relation to Other Specifications
This section provides an overview of the relation of the RDCEO to other specifications. More details on specifics and examples of use appear in other sections. The specifications mentioned in this section contain useful descriptions of the "bigger picture" of applications into which the RDCEO fits.
3.1 Within the Framework of 1EdTech Specifications
1EdTech Specifications and Implementation Handbooks may all be found on the 1EdTech website: http://www.imsglobal.org/.
3.1.1 1EdTech Guidelines for Globally Unique Identifiers
There is an existing Implementation Guide from 1EdTech: 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0 (IMSPLID). Section 4.1.2 explains some of the issues relating to the use of various forms of identifier.
3.1.2 LOM (and 1EdTech Meta-Data) as Used in a RDCEO Instance
A RDCEO may contain an optional 1EdTech meta-data record for the reusable definition. Useful meta-data include additional identification as a catalog entry, information about the author, the creation date, and the coverage (in the sense of the Dublin Core as adopted by the 1EdTech Meta-Data Specification.) The <relation> element may be used to relate a definition to a prior version of the definition.
3.1.3 Reference to a RDCEO in LOM (and 1EdTech Meta-Data)
The LOM contains a number of places where references to externally-defined tokens is possible. The classification construct is the most obvious place where references to RDCEOs would be most valuable, as the applications described in section 2.3.2 show. In particular, there are two classification types (purposes in LOM terminology) listed in the IEEE LOM Standard and 1EdTech Meta-Data v1.2 Specification: educational objective and prerequisite.
3.1.4 Learner Information Packaging (LIP) Information Model
The LIP model has direct and indirect uses for RDCEOs and the LIP specification provides excellent descriptions of applications where RDCEOs would be relevant. Direct uses are illustrated in the Application examples (section 6.4) and are references to RDCEOs as goal or competency entries in the profile. Indirect uses are those where something like a certificate is referenced from the LIP and the certificate in turn may reference an RDCEO.
3.1.5 Bundling Using Content Packaging
An 1EdTech implementation handbook, "Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications Version 1.0" (IMSBUND), sometimes called the "Bundling Guide" contains, among other things, guidance on how to package LIP XML with other documents and data. This is clearly applicable to cases where LIP XML instances reference RDCEOs and there is no confidence that the receiver knows or can retrieve a definition.
It must be noted that the Bundling Guide referred to a specification called "Competency v1.0" that did not actually exist at the time, whereas this specification does not bear this name. A type identifier "imsrcd_xmlv1p0" was associated with "Competency v1.0". This name and type identifier are not to be considered deprecated synonyms for "Reusable Definition of Competency and Educational Objective 1.0" and "imsrdceo_xmlv1p0". They may be removed from future versions of the Bundling Guide.
The Bundling Guide does not include an example of including RDCEO XML instances since there was no RDCEO specification at the time of its writing. In some cases it may be practicable to include RDCEO XML instances as one of the files in a <resource> container. In other cases, where the LIP XML does not refer to a specific RDCEO XML file but uses the RDCEO identifier, a separate <resource> element should be used and the <dependency> element employed to indicate to a processing system that there are supporting files that it may elect to process. The typing of the resource to be "imsrcd_xmlv1p0" permits the processing system to determine the relevance of contained files without inspecting their content.
3.1.6 Simple Sequencing
1EdTech Simple Sequencing, currently a public draft specification, provides a way to reference competencies by identifier as a way of breaking out from sequencing that is purely content-centric. Since the sequencing model relies upon persistent and objective measures, there is a clear application for the RDCEO.
3.2 Related Specifications
3.2.1 IEEE LOM
IEEE 1484-12:2002, Standard for Learning Object Metadata is newly available as an information model at the time of writing. It shares a common background with 1EdTech Meta-Data v1.2 and there is likely to be some 1EdTech activity to harmonize with it. In general, the information models are very close and the applications described in this document apply equally to 1EdTech Meta-Data v1.2 or IEEE LOM, for which an XML binding is under preparation.
3.2.2 HR-XML Competencies
The HR-XML Consortium has, until recently, been on a separate track from 1EdTech Consortium. This reflects our relative starting points of human resource management and e-learning. Both consortia have been aware of the significance of the domain of the other. The RDCEO specification is a clear touch-point between our two specification activities.
The HR-XML specification "Competencies 1.0 (Measurable Characteristics)" contains a good description of HR domain issues and business reasons that relate well to the RDCEO specification. An example showing how an RDCEO can fit into a HR-XML Competencies record is given in section 6.3.
4. Implementation Guidance
4.1 Using the RDCEO Data Structures
The semantics of the elements is described in the Information Model document in the RDCEO specification and the XML Binding document provides further information on using these in XML. This section provides additional implementation guidance and should be understood in relation to these two documents.
4.1.1 <rdceo>
This is the root element of the XML instance. It contains a single reusable definition, present as a fragment in a collection, possibly a published catalog, or may be a copy of another RDCEO. Copies of definitions include cases where an entire catalog is duplicated for convenience or application necessity. When any definition is processed or stored, care must be taken to preserve the information. The sections on identifiers and meta-data contain specific cautions to be remembered when managing RDCEOs. It is significant, though, that a copied definition does not have to be a clone of the XML. For example:
- statement identifiers may be changed.
- repeated <statement>, <definition>, and <langstring> elements may be reordered since the ordering of repeated elements has no significance.
In some applications it may also be legitimate to add new <langstring> elements to contain a translation of existing data into another human language.
It is possible to apply meta-data at the level of <rdceo>. It is recommended that meta-data at this location be used, if required, to:
- specify the RDCEO schema and version.
- provide other-related information such as lifecycle data, relation if this RDCEO supersedes a previously published RDCEO, classification, etc.
In the future, it may be the case that another version of the RDCEO specification may be released with a different XML namespace. In this case all XML elements defined in the RDCEO Binding should use the same namespace.
4.1.2 RDCEO Identifiers
4.1.2.1 Identifier Concept and Application
The single most important consideration when using the RDCEO identifier is that it should be unique. In the absence of global identifier registries, this can be achieved practically by dividing the identifier into two parts: catalog and entry. Always consider the identifier to have these parts, irrespective of the binding used to exchange the identifier and the way a particular implementation stores it. It would, for example, be entirely legitimate for a system to receive a definition with an identifier in catenated form and transmit the same definition with a separated identifier; the underlying information is the same, therefore the data is the same.
Closed systems may choose to use the RDCEO specification as a convenient exchange binding and use an opaque identification scheme. Open systems can maximize interoperability by preferring to adopt one of the following practices.
Either use a robust scheme such as URN with a registered namespace identifier and include sufficient information to allow receiving systems to resolve the URN into a definition, or use URLs as follows:
- Make the "catalog" be a valid URL (but not using "#" character).
- Make the "entry" a valid URI fragment identifier.
- Publish a master reference RDCEO XML instance at the URL given for the "catalog".
- Only use URLs for domains under the control of the defining authority and with local control mechanisms to ensure that catalog identifiers are not duplicated.
This approach provides a natural way for an identifier to be resolved into a location and XML fragment. It is essential that any system using public data or exchanging data with another system must not assume that the practice described above has been followed; graceful degradation for cases where other practices have been followed is highly desirable.
4.1.2.2 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook
The approach to identifiers taken in the RDCEO Information Model follows that of the IEEE LOM Standard that specifies that a resource identifier is composed of a catalog value and an entry value. The RDCEO Binding allows the URN approach described in the 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0 (IMSPLID). The RCDEO binding also allows the binding of the identifier as a simple URI or as a URI reference for situations where a URN is not practical. The URI reference scheme defines a string that contains two fragments separated by a "#" character (Unicode hexadecimal 23). Like the URN described in the 1EdTech Handbook, this allows two-part resource identifiers to be practically constructed. In the absence of existing best practice in this very important area, no specific guidance is presented here but it is noted that:
- URNs are of the general form "URN:<NID>:<NIS>", where "URN:<NID>" contains the catalog value and "<NIS>" contains the entry value of the RDCEO two-part identification model.
- If a URI reference syntax is used rather than a URN, the <identifier> element must contain both the catalog and the entry values, separated by a "#" character. The result of this concatenation must be a valid URI reference. URI references are described in RFC 2396, Clause 4.
- If the <identifier> string is a URI that is not a URN or a URI reference, i.e. it does not contain a "#" character, the catalog value is assumed to be nil.
The 1EdTech Handbook describes various delimited scheme/source syntaxes that could be mapped to the catalog+entry form used in this specification.
4.1.3 <title> and <description>
These are the free-text representations for the reusable definition. Title is mandatory and should be concise; the optional description can contain an unstructured elaboration, possibly containing text that is similar to the content of the structured definition (i.e., the content of <statement> elements). The description could be used to present a definition that is intelligible to someone who does not understand the idea of a model or the details of the model used in the structured definition, or if the reusable definition does not exist in a structured model.
Title and description are both human language entries, with multiple-language representations possible. In general it is recommended that the human language be identified using the xml:lang attribute described in the XML Binding document whether or not multiple language representations are actually present. It should be noted that there is only one title per reusable definition; there may only be one <langstring> entry per language.
4.1.4 <definition>
The optional <definition> element contains a structured definition in terms of a set of statements. The significance of each statement may be clarified by declaring or documenting the use of a model and identifying the role of each statement (the Statement Name) within the model. Although the model and statement name identification are optional, it is recommended that they both be used if a structured definition is present. It is meaningless to declare a model unless each statement has a statement name. Using statement names in the absence of a model is not recommended since the model defines the context for the statement name.
Multiple <definition> elements may appear in a reusable definition. This could be used if the same competency or educational objective is being described in different models. If more than one <definition> appears then each must declare use of a different model (at most one definition is permitted to contain an undeclared model). It is not clear how this might be used in practice; it is unlikely that a single RDCEO would be modelled by two organizations because they would probably also use different identifiers but plausible that an organization might apply two models. This might be used in practice to provide different models for different users of the RDCEO: learner-centred for the learner etc. This might also be used when existing definitions that use outdated or disparate models are incorporated into new RDCEO instances that uses a common formal definition model. For example, this may happen when two enterprises merge and must reconcile the skill models they use to define training objectives.
4.1.4.1 <model>
The model can be identified by any string, but a human-language title is not advised. It will usually not contain sufficient information to explain the model and may not be unique. The model is expected to be an opaque and controlled term. It can usefully be the URL to a document that describes the definition model and the semantics of the various components in it. This could be an HTML page designed for human reading or an XML file that could be read and used by software tools (no schema for this is defined but it may be possible to apply vocabulary or taxonomy definition schemas).
The model identification makes the interpretation of the statement names unique, for example making the use of "criterion" distinct to a context. The model defines what the set of valid statements may be, whether any are optional or repeatable. How the model itself defines these things is out of scope for this specification but would be an important consideration for any community of practice and form part of any application profile using RDCEOs.
Current practice tends to be that organizations have a preferred model and produce one or more catalogs using their model. In the future we may see this specification promoting shared models since this will enhance the interoperability that the RDCEO specification seeks to develop.
4.1.4.2 <statement>
Each statement will typically be named using the statementname attribute to identify its role within a structured definition model. The order of statements has no significance, only the statement name confers significance. The information that an XML instance represents is an unordered list of statements; XML instances that differ only in the order of <statement> of elements are of identical RDCEOs. Statements with a given name may be repeated if the model permits.
Each statement may have an identifier attribute that is not significant in terms of the definition; it is a locally-unique label that an implementation may use to keep track of statements during processing. Indeed, there is no requirement that the identifier attribute of a statement be preserved when a RDCEO instance is processed, re-transmitted etc.
Statements can be of two types: human language entries using <statementtext> or tokenized entries using <statementtoken>. <statementtext> is used in the same way as <title> and <description> and should provide enough information in human-readable form to be completely intelligible in the context of a specified model. <statementtoken> allows the use of vocabularies; the token (vocabulary term or "value") occurs with a <source> element to define the origin of the term. This approach to controlled terms (vocabularies) follows that used in 1EdTech Meta-Data v1.2 and IEEE LOM. The token is just a string; it does not have to be a human language word and does not have to be meaningful. The "source" typically defines the meaning of the token, either by reference to a specification or possibly the data in the <source> element is a URL to a human or machine-readable description of the vocabulary terms.
4.1.5 <metadata>
Meta-data may appear at the level of the reusable definition (<rdceo>). Rather than inventing a new and different data model, the RDCEO specification recommends that you use relevant meta-data elements already defined in Learning Object Metadata (LOM) to describe the RDCEO.
4.2 Distributed Architectures and Considerations
The value of a reusable definition becomes clear when distributed architectures are considered. It is useful to consider some practices that will promote interoperability in a distributed milieu since not all practices will work well. In developing this specification, current preferences for the application of Internet-based technologies have been assumed; 1EdTech specifications do not re-invent infrastructure.
The reader should understand that this specification does not seek to define the architectures for e-learning or any other system but acknowledges that someone will need to do this: using Java RMI, SOAP, plain Web publication, etc. These may be usefully divided into cases where an API is defined and where raw data is available. Both are bound to be built to use the RDCEO and to rely upon the RDCEO identifier being persistent and location independent.
The persistence and location independence of identifiers is crucial not only in ensuring that the definitions are meaningfully reusable but also in practical implementations. Publishers of definitions and creators of repositories should permit the caching of definitions such that systems can maintain local databases and resolve references to RDCEOs that have previously been received by the system.
It is clear that there will never be a universal repository of reusable definitions. Consequently, it will be important that techniques to discover the content of a definition from its identifier alone are tractable. The best practices in the use of identifiers in section 4.1.2 should assist this process but some applications will follow alternative approaches.
5. Basic examples of RDCEO instances
All of the examples in this section are illustrative of ways in which information could be represented using an RDCEO instance. There will be many other valid possibilities. None of these examples has been vetted by any organization mentioned to check the mapping of information onto the RDCEO Information Model.
All of the RDCEO identifiers and models used are completely fictional. Any URL used for catalog or model identification will not exist.
All of the examples in this section are released as XML files with this specification. They have been checked for validity using:
5.1 Minimal Example
Only title and RDCEO identifier are mandatory. Below is an XML fragment showing an example of this information.
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#minimal_eg</identifier>
<title>
<langstring xml:lang="en">Minimal Example - Mandatory Elements Only </langstring>
</title>
</rdceo>
5.2 Use of URN for Identifier
The first fragment contains an identifier based on the examples in the 1EdTech PLID Handbook (IMSPLID).
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>URN:1EdTech-PLIRID-V0:ISBN#:0-201-83599-1</identifier>
<title>
<langstring xml:lang="en">Testing URN</langstring>
</title>
</rdceo>
The second example shows character escaping. In this case the RDCEO would have a full URN of "URN:PublicID:foo%23bar1"
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>URN:PublicID:foo%23bar1</identifier>
<title>
<langstring xml:lang="en">Testing URN</langstring>
</title>
</rdceo>
5.3 A Made-Up Example of a Competency in Reading 1EdTech Specifications
This example illustrates the use of the generic element extension mechanism to include meta-data. It also includes a model element containing descriptive text. This is valid but not advised in general.
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#pass_eg</identifier>
<title>
<langstring xml:lang="en-US">Reading 1EdTech specifications</langstring>
</title>
<description>
<langstring xml:lang="en-US">Reads and understands 1EdTech Consortium specifications</langstring>
</description>
<definition>
<model>1EdTech Competency WG</model>
<statement statementname="Performance">
<statementtext>
<langstring xml:lang="en-US">Reads and understands 1EdTech Consortium specifications</langstring>
</statementtext>
</statement>
<statement statementname="Conditions">
<statementtext>
<langstring xml:lang="en-US">Has access to a published specification including the information model, the XML binding, and the best practices guide</langstring>
</statementtext>
</statement>
<statement statementname="Criteria">
<statementtext>
<langstring xml:lang="en-US">Demonstrates an understanding of the content of specifications documents by verbally summarizing their content and creating valid sample XML representations of appropriate data from use cases similar to those discussed in the information model and/or best practices document.</langstring>
</statementtext>
</statement>
</definition>
<metadata>
<rdceoschema>1EdTech RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
<lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1">
<lifecycle>
<contribute>
<role>
<source>
<langstring xml:lang="x-none">LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang="en">Author</langstring>
</value>
</role>
<centity>
<vcard> BEGIN: vCard
FN:Robby Robson
END:vCard </vcard>
</centity>
</contribute>
</lifecycle>
</lom>
</metadata>
</rdceo>
5.4 A Core Competency for CPAs
(The source for this competency is http://www.cpavision.org/poll/corecomp.cfm. See CPA in the references)
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#cpa_eg</identifier>
<title>
<langstring xml:lang="en-US">Team Player</langstring>
</title>
<description>
<langstring xml:lang="en-US">Able to effectively execute work as a team member. </langstring>
</description>
<metadata>
<rdceoschema>1EdTech RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
</metadata>
</rdceo>
5.5 A High School Competency (Outcome) from (NOICC)
(The source for this is http://www.academicinnovations.com/noicc.html. The statementnames in the definition ("Category", "Statement", and "Performance Indicators") do not appear on the site but are used to illustrate the RDCEO specification.)
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#noicc_eg</identifier>
<title>
<langstring xml:lang="en-US">COMPETENCY IV </langstring>
</title>
<description>
<langstring xml:lang="en-US">COMPETENCY IV: Understanding the relationship between educational achievement and career planning.</langstring>
</description>
<definition>
<model>http://www.academicinnovations.com/noicc.html</model>
<statement statementname="Category">
<statementtext>
<langstring xml:lang="en-US">Educational and Occupational Exploration</langstring>
</statementtext>
</statement>
<statement statementname=" Statement ">
<statementtext>
<langstring xml:lang="en-US">Understanding the relationship between educational achievement and career planning.</langstring>
</statementtext>
</statement>
<statement statementname="Performance Indicators">
<statementtext>
<langstring xml:lang="en-US">Demonstrate how to apply academic and vocational skills to achieve personal goals. Describe the relationship of academic and vocational skills to personal interests. Describe how education relates to the selection of college majors, further training, and/or entry into the job market. Demonstrate transferable skills that can apply to a variety of occupations and changing occupational requirements. Describe how learning skills are required in the workplace.</langstring>
</statementtext>
</statement>
</definition>
<metadata>
<rdceoschema>1EdTech RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
</metadata>
</rdceo>
5.6 A Proficiency for Admissions to College in Oregon (PASS)
(This is Oregon PASS Social Science Proficiency D taken from http://www.ous.edu/pass/docs/pdf_documents/standards/social_science.pdf .)
The definition is constructed with a single <statement>, "criteria" containing an aggregate of a number of criteria. Example 5.7 shows an alternative approach where each criterion is separated into a different <statement>, each with the same statementname.
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#pass_eg</identifier>
<title>
<langstring xml:lang="en-US">Oregon PASS Social Science Proficiency D</langstring>
</title>
<description>
<langstring xml:lang="en-US">Oregon PASS Social Science Proficiency D: Understand Structures and Systems of United States Government. Understand the principles, purposes, structures, and functions of government in the United States: its philosophical basis and historical evolution; the structure of power, authority, and governance; the relationship of the states to the federal government; the Constitution and Bill of Rights; the dynamics of conflicting rights and interests in the American political system; the role and responsibilities of citizenship; and patterns of democratic participation in American politics. Compare other forms of government and political systems to those found in the United States.</langstring>
</description>
<definition>
<model>http://www.uoregon.edu/pass</model>
<statement statementname="Content Area">
<statementtext>
<langstring xml:lang="en-US">Social Sciences</langstring>
</statementtext>
</statement>
<statement statementname="Proficiency">
<statementtext>
<langstring xml:lang="en-US">D: Understand Structures and Systems of United States Government.</langstring>
</statementtext>
</statement>
<statement statementname="Criteria">
<statementtext>
<langstring xml:lang="en-US">D1: Understanding of U.S. Government Principles: Understand the philosophy and principles upon which the government of the United States is based.
D2: Understanding of U.S. Government System Apply understanding of the interrelationships among purposes, systems, structures, and functions of U.S. government.
D3: Understanding of U.S. Political System: Apply understanding of the U.S. political system and citizens' rights and responsibilities as informed, ethical participants.
D4: Comparison and Interaction with Other Governments: Understand how other governmental and political systems compare and interact with those of the United States.
</langstring>
</statementtext>
</statement>
</definition>
<metadata>
<rdceoschema>1EdTech RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
</metadata>
</rdceo>
5.7 A Conformance Statement for SCORM Compliance Phrased as a Competency Definition
This example is inspired by an ADL SCORM Conformance Definition. This shows the general applicability of competency definitions - in this case as a conformance statement. The "competency" applies to a product. Compare the repeated "criteria" statements with the approach of example 5.6. Note also that both forms of the identifier are present and agree.
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/fictional/rdceo_cat1.xml#scorm_eg"</identifier>
<title>
<langstring xml:lang="en-US">SCORM 1.1 LMS Runtime Conformance </langstring>
</title>
<description>
<langstring xml:lang="en-US">A learning management system which conform to the SCORM 1.1 specification for runtime environment conformance. The LMS must (1) conform with section 6 of the SCORM version 1.1, (2) launch SCORM version 1.1 Conformant Assignable Unit, (3) implement all of the API calls correctly, (4) fully support mandatory CMI data model elements and at a minimum can store (LMSSetValue and LMSGetValue) optional CMI data model elements across a single session.</langstring>
</description>
<definition>
<model>http://www.adlnet.org/scorm/conformacevocab/</model>
<statement statementname="conformance">
<statementtext>
<langstring xml:lang="en-US">Conformant with section 6 of the SCORM version 1.0 </langstring>
</statementtext>
</statement>
<statement statementname="condition">
<statementtext>
<langstring xml:lang="en-US">Using SCORM 1.1 Conformant Assignable Unit</langstring>
</statementtext>
</statement>
<statement statementname="criterion">
<statementtext>
<langstring xml:lang="en-US"> Launches SCORM version 1.a Conformant Assignable Unit</langstring>
</statementtext>
</statement>
<statement statementname="criterion">
<statementtext>
<langstring xml:lang="en-US">Implements all of the API calls correctly</langstring>
</statementtext>
</statement>
<statement statementname="criterion">
<statementtext>
<langstring xml:lang="en-US">Fully supports mandatory CMI data model elements and at a minimum can store (LMSSetValue and LMSGetValue) optional CMI data model elements across a single session of the AU.</langstring>
</statementtext>
</statement>
</definition>
<metadata>
<rdceoschema>1EdTech RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
</metadata>
</rdceo>
5.8 Example Using 1EdTech Meta-Data in RDCEO Instance
Example 5.3 shows how the namespace extension mechanism may be employed to identify authorship as an aspect of the lifecycle. The <lifecycle> can also include version and status information that could be valuable in the context of a RDCEO. Versioning also properly requires some form of audit trail. This can be achieved using the <relation> structure from 1EdTech Meta-Data v1.2 as in the following example. It is possible to use the relation construct to build maps and taxonomies of RDCEOs. This specification makes no specific recommendation for or against such a use but cautions that any approach should be suitable for a distributed information architecture.
This example declares that it is a version of, therefore a successor, to the definition at the start of section 6. It uses two forms of identifying the definition it is related to: using the <identifier> and <catalogentry>. Only one of these is necessary and a receiving system needs to anticipate cases like this where there are legitimate choices. Note that the decision to use <identifier> or <catalogentry> is independent of the binding choice in the RDCEO: catenated or separate identifier. The IEEE LOM Specification also allows relations to be expressed in terms of identifier or catalogentry.
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/examples/competencies.xml#definition1b</identifier>
<title>
<langstring xml:lang="en">Reads and Understands W3C Schema</langstring>
</title>
<description>
<langstring xml:lang="en">Can read and understand W3C Schema Language 1.0</langstring>
</description>
<metadata>
<lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1">
<relation>
<kind>
<source>
<langstring xml:lang="x-none">LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang="x-none">isVersionOf</langstring>
</value>
</kind>
<resource> <identifier>http://www.imsglobal.org/examples/competencies.xml#definition1</identifier>
<catalogentry>
<catalog>http://www.imsglobal.org/examples/competencies.xml</catalog>
<entry>
<langstring xml:lang="x-none">definition1</langstring>
</entry>
</catalogentry>
</resource>
</relation>
</lom>
</metadata>
</rdceo>
6. Application examples
In each of these examples, there is assumed to be an RDCEO:
<?xml version="1.0" encoding="utf-8"?>
<rdceo xsi:schemaLocation="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0 imsrdceo_rootv1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns="http://www.imsglobal.org/xsd/imsrdceo_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<identifier>http://www.imsglobal.org/examples/competencies.xml#definition1</identifier>
<title>
<langstring xml:lang="en">Reads and Understands W3C Schema</langstring>
</title>
<description>
<langstring xml:lang="en">Can read and understand W3C Schema Language 1.0</langstring>
</description>
</rdceo>
The examples in this section do not carry the endorsement of organizations mentioned.
6.1 1EdTech Meta-Data v1.2
The example uses the 1EdTech Consortium, Inc., Meta-Data Specification, 2001-October-01.
Since we do not consider structures or frameworks of definitions in this specification, there is not a ladder of taxon elements. It remains to be determined whether best practice would present a ladder even if a structure/framework is known since non-hierarchical networks are likely. However, there are current examples of hierarchical competency models that would support the use of a taxon ladder in the meta-data describing how the RDCEO can be classified.
In cases where multiple language titles exist in a definition, it would be possible to present multiple <langstring> elements for <entry>.
A similar structure could be used with a purpose ="Prerequisite".
<?xml version="1.0" encoding="UTF-8"?>
<lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd">
<classification>
<purpose>
<source>
<langstring xml:lang="x-none">LOMv1.0</langstring>
</source>
<value>
<langstring>Educational Objective</langstring>
</value>
</purpose>
<taxonpath>
<source>
<langstring xml:lang="x-none">
http://www.imsglobal.org/examples/competencies.xml
</langstring>
</source>
<taxon>
<id>definition1</id>
<entry>
<langstring xml:lang="en">Reads and Understands W3C Schema</langstring>
</entry>
</taxon>
</taxonpath>
</classification>
</lom>
6.2 IEEE LOM
A binding of IEEE 1484-12:2002, Learning Object Metadata is not currently available but it is possible to consider an example in terms of the LOM information model. This is seen to correlate with the 1EdTech Meta-Data v1.2 example above. Implementations using 1EdTech Meta-Data v1.2 with 1EdTech RDCEO may be confident that mapping to a LOM binding is likely to be trivial.
6.3 HR-XML Competencies 1.0
HR-XML Consortium, Competencies 1.0 (Measurable Characteristics) Recommendation, 2001-Oct-16.
All elements and attributes are optional in the HR-XML Competencies specification and the example here is a minimal reference to a RDCEO. The HR-XML Competencies specification permits additional data elements for competency evidence and competency weighting as well as permitting nesting and reference to competency taxonomies. It is not clear what best practice would be: for example how nested competencies and taxonomies relate, whether a RDCEO catalog would be seen as a special case taxonomy or whether the ownerId is properly a RDCEO catalog identifier.
<Competency description="Can read and understand W3C Schema Language 1.0"
name="Reads and Understands W3C Schema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Competencies-1_0.xsd">
<CompetencyId description="1EdTech Example Competency Catalogue"
id="definition1"
idOwner="http://www.imsglobal.org/examples/competencies.xml"/>
<!-- omitted evidence data etc -->
</Competency>
An alternative formulation might be:
<Competency description="Can read and understand W3C Schema Language 1.0"
name="Reads and Understands W3C Schema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Competencies-1_0.xsd">
<CompetencyId description="1EdTech Example Competency Catalogue"
id="http://www.imsglobal.org/examples/competencies.xml#definition1"/>
<!-- omitted evidence data etc -->
</Competency>
Or, with a RDCEO identified using a URN:
<Competency description="Can read and understand W3C Schema Language 1.0"
name="Reads and Understands W3C Schema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Competencies-1_0.xsd">
<CompetencyId description="1EdTech Example Competency Catalogue"
id="URN:X-1EdTech-PLIRID-V0::6ba7b8149dad11d180b400c04fd430c8"/>
<!-- omitted evidence data etc -->
</Competency>
6.4 1EdTech Learner Information Package
These examples use the 1EdTech Consortium Inc., Learner Information Package Specification, 2001-March-09.
6.4.1 Learner Competency Data
In this example the "full definition" contains a complete catenated identifier of the RDCEO. A processing system should treat this data as such and decide whether it has a local definition if one is required. If not, it could attempt to acquire the definition by treating the "full definition" as the locator for one or more definitions since it is a valid URL. In the case where XML instances are packaged using the 1EdTech Bundling Guide advice then references to a local file containing definition(s) may be found and processed first.
<?xml version="1.0" encoding="UTF-8"?>
<learnerinformation xmlns="http://www.imsglobal.org/xsd/ims_lip_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/ims_lip_rootv1p0 ims_lip_rootv1p0.xsd">
<contentype>
<referential>
<sourcedid>
<source>http://www.imsglobal.org/examples/rcd/</source>
<id>lip_example2</id>
</sourcedid>
</referential>
</contentype>
<competency>
<contentype>
<referential>
<indexid>competency1</indexid>
</referential>
</contentype>
<description>
<short xml:lang="en">Reads and Understands W3C Schema</short>
<long xml:lang="en">Can read and understand W3C Schema Language 1.0</long>
<full>
<!--The educational objective definition and its control document are available as an xml file local to this learnerinformation xml file.-->
<media encoding="uri" mediamode="Text" mimetype="text/xml">http://www.imsglobal.org/examples/competencies.xml#definition1</media>
</full>
</description>
</competency>
</learnerinformation>
Bundling would be a good option if URN identifiers were used, for example as in:
<media encoding="uri" mediamode="Text" mimetype="text/xml"> URN:X-1EdTech-PLIRID-V0::6ba7b8149dad11d180b400c04fd430c8 </media>
6.4.2 Learner Goal Record (with Local Definition of Educational Objective)
This relates to the identical definition as the competency examples but relates to an educational objective.
In this example, the definition of the educational objective is held in a local file. Since only a file name is given it is to be assumed that it contains a single definition.
<?xml version="1.0" encoding="UTF-8"?>
<learnerinformation xmlns="http://www.imsglobal.org/xsd/ims_lip_rootv1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/ims_lip_rootv1p0 ims_lip_rootv1p0.xsd">
<contentype>
<referential>
<sourcedid>
<source>http://www.imsglobal.org/examples/rcd/</source>
<id>lip_example3</id>
</sourcedid>
</referential>
</contentype>
<goal>
<contentype>
<referential>
<indexid>goal1</indexid>
</referential>
</contentype>
<date>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Create</tyvalue>
</typename>
<datetime>2001-08-15</datetime>
</date>
<status>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Active</tyvalue>
</typename>
</status>
<description>
<short xml:lang="en">Reads and Understands W3C Schema</short>
<long xml:lang="en">Can read and understand W3C Schema Language 1.0</long>
<full>
<!--The educational objective definition and its control document are available as an xml file local to this learnerinformation xml file.-->
<media encoding="uri" mediamode="Text" mimetype="text/xml">eo1.xml</media>
</full>
</description>
</goal>
</learnerinformation>
6.5 1EdTech Simple Sequencing
This example is speculative as the Simple Sequencing specification is not final, but is based on existing practice that uses similar principles.
The 1EdTech Simple Sequencing specification allows the association of Objective IDs with activities. The ID is a link to the corresponding objective information. The same objective ID may be associated with more than one activity; for example, one activity may be a pre-test on a learning objective, and another a tutorial that is delivered only if the learner failed on the pre-test.
The ID may be local to the activity, local to the activity tree or global. The ID is resolved to the most global scope possible to obtain the data. If the ID cannot be resolved, a local objective (and thus local objective information) is instantiated for the activity. Resolution of the scope of the ID is not specified by Simple Sequencing. Establishment of global registry of objective data is not specified by Simple Sequencing. However, a course publisher might use RDCEO identifiers at the value for Objective ID in the activity trees included in the course packages. This would allow a compatible Learning Management System to track and possibly initialize the tracking status information for those learning objectives across multiple courses. The RDCEO identifiers can also be used to look up the human-readable definition of the objective or to map course tracking information to a competency or task model that uses the same RDCEO identifiers.
6.6 Fictional Examples
The application examples show a data-centric view. Obviously, in a presentation to human beings the various GUIDs would be used as the key to look up the actual RDCEO titles and other human-readable data for display to the user.
Note: These examples are made-up XML bindings that are not necessarily those of any real implementation, and do not necessarily correspond to any current standard specification. The only standard element is the reference to a RDCEO. In these examples, it is the value of data element named "rdceoid". The values themselves are fanciful. Refer to the 1EdTech GUID Guidelines for details on how to build compliant GUID values.
6.6.1 A Competency Certificate
A basic competency certificate is mostly made of references: reference to the person (or team) who has the competency, to the competency being certified, and to the entity that issued the certificate. For convenience and performance, such a certificate can also contain information that could otherwise be obtained through a lookup using those basic data elements. Such detail information can include data about how and when the certificate was obtained, an expiration date, etc.
<certificate>
<guid>xyz-acme.com:20010809ABDFECAEF-5648</guid>
<personguid>123456-ACXX-12345</personguid>
<issuerguid>xyz-acme.com</issuerguid>
<rdceoid> http://www.imsglobal.org/examples/competencies.xml#definition1</rdceoid>
<details>
<rating>
<method>Scored Exam</method>
<score>.83</score>
<proctored>true</proctored>
</rating>
<date>
<stddate mode="Issue"/>
<datetime>200108091234</datetime>
</date>
<date>
<stddate mode="Expiration"/>
<datetime>200408092359</datetime>
</date>
</details>
</certificate>
6.6.2 A List of Desired Competencies Resulting from Skill-Gap Analysis
Skill gap analysis typically compares required competencies with acquired competencies. If those are stored as RDCEOs, the analysis system can simply compare lists of GUIDs rather than trying to analyze textual descriptions. The result of a simple analysis is in effect the list of desired competencies for which there are no corresponding acquired competencies in a person's profile. <rdceoid>URN:X-1EdTech-PLIRID-V0::6ba7b8149dad11d180b400c04fd430c8</rdceoid>
<rdceoid>URN:X-1EdTech-PLIRID-V0::6ba7b8149dad11d18000a1c14fd430c8</rdceoid>
<rdceoid>URN:X-1EdTech-PLIRID-V0::6ba7b8149dad11d180b400c04fd443e0</rdceoid>
6.6.3 A Skills Hierarchy
Skills are often decomposable in subskills. Each one of those, including the overall skill, can be represented by a separate RDCEO, and the hierarchical relationship can be expressed by nesting in a "skill map".
<skill rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1">
<skill rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1a">
<skill rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1b">
<skill rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1ba"/>
<skill rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1bb"/>
</skill>
</skill>
6.6.4 A Hiearchical Tree of Learning Objectives
<tlo rdceoid=" http://www.imsglobal.org/examples/competencies.xml#definition1"> <elo rdceoid=" http://www.imsglobal.org/examples/competencies2.xml#definition1"/> <elo rdceoid=" http://www.imsglobal.org/examples/competencies2.xml#definition2"/> </tlo>
6.6.5 A Fragment of a Complex Map of Related Competencies
This fragment is a single node in what could be a map of thousands of nodes. Such maps can correspond to cognitive mapping of a topic, or they can be used to manage equivalencies between competency definitions from various sources, etc.
<node> <rdceoid> http://www.imsglobal.org/examples/competencies.xml#definition1</rdceoid> <relation> <kind>requires</kind> <rdceoid> http://www.imsglobal.org/examples/competencies.xml#pre1</rdceoid> </relation> <relation> <kind>contains</kind> <rdceoid> http://www.imsglobal.org/examples/competencies.xml#atomic1</rdceoid> </relation> <relation> <kind>equivalent</kind> <rdceoid> http://www.fictional.org/a.xml#eo1</rdceoid> </relation> </node>
Appendix A - Case Study, UK Learning and Skills Development Agency (LSDA)
The UK Learning and Skills Development Agency (LSDA) is typical of national or state bodies with a responsibility for supporting education and skills. Over recent years they have been working to develop, validate, trial, and promote a "credit framework" (http://www.lsda.org.uk/programmes/credit/) to support a wide range of activities to support education and training and its administration. They identified the 1EdTech Reusable Competency Definition public draft specification, that has evolved into this specification, as a potentially very useful tool in their work to expand the application of the framework and produced a discussion paper that provided the source for this appendix.
Much thinking on learning outcomes is rooted in pre-knowledge economies. The model presented here offers an individualized structure, which is learner-centered rather than based on descriptive course-centered language. It is felt that this model offers greater possibilities for interoperability and compatibility with other specifications. In particular it is most relevant to new developments in teaching and learning which make use of technology platforms.
A1 - Requirement Statement
The framework presented here is based on research and development by the UK's Learning and Skills Development Agency (LSDA). It uses a system of 'learning outcomes', 'units of assessment' and 'credit' (which are described in detail below).
The framework is a universal way to:
The framework has been used successfully in academic, vocational, and workplace contexts, and at all levels from basic education to university/professional qualifications. Any specification of learning outcomes must permit description of more than industry skills competence but include wider education and training contexts.
If learning could be specified using a standard model, and linked to existing or planned specifications for learning object meta-data, learner information, question and test interoperability etc., learners might effectively discover material (and be assessed, their learning tracked, etc.) for particular purposes and at particular times.
The developing UK thinking and practice, based on the LSDA framework detailed later, represents wide professional consensus and use in a range of education and training settings. It was, for example, presented to a March 2000 IEEE seminar in London and met with a favorable reception.
The approach has been endorsed by UK national training organizations (NTOs), organizations and institutions in higher education/university level, university credit consortia, academic and vocational awarding bodies, the UK University for Industry (UfI), and other key UK agencies. It has also been accepted by the assemblies (devolved governments) for Scotland, Wales, and Northern Ireland.
- work by the LSDA and other agencies over recent years to specify learning outcomes within a coherent framework.
- the recognition that a coherent 'map' of learning outcomes (what learners know, understand and/or can do at whatever level and of whatever 'volume') could fit logically onto a map of learning objects (for purposes outlined below).
The framework - and this specification - can give confidence in learning assessment regimes which are based on social and cultural realities whatever the institution or country.
- linking so-called 'units of assessment', and allowing learners to
- combine units of assessment in a variety of different ways to meet particular specific needs.
Whole learning programs and qualifications can be based on combinations of units, which are tailored for the needs of individuals, employers, and selectors for college and university courses. Units are derived by learners/tutors/trainers/peers within a framework, which is adaptable to different circumstances as outlined in this specification. Learners can be offered individual outcomes to meet their needs, as in the example below.
A2 - What the Framework Is
At the heart of the framework is the unit specification. This includes:
- Title - what the unit is called.
- Learning outcomes - statements of what a learner can be expected to know, understand and do.
- Assessment criteria - criteria for judging whether learning outcomes have been achieved.
- Credit value - based on volume of achievement/notional learning time.
- Notional learning time - the time taken on average for a learner to achieve a set of learning outcomes at a specified level.
- Level - the degree of complexity, learner autonomy and range of achievement derived from level descriptors.
- Size - the extent of learning represented by the notional learning time required to achieve the unit.
Units do not specify how, where or when learning takes place. The relationship between units and provision therefore becomes totally flexible. The outcomes of a unit may be achieved through a single learning activity. Outcomes may be reached through two or more activities - or one activity can contribute to the achievement of a number of units.
For example learning to use a computer-aided design (CAD) software package could contribute to a unit in CAD, or to units in CAD, maths, communication, and team working. An infinite number of combinations and permutations of episodes, units, and outcomes becomes possible.
Although the framework is neutral as to how learning outcomes and units may be combined, it is recognized that for coherence users of the framework (providers, awarding bodies, standard setting agencies, materials developers) may specify combinations to meet particular requirements. Designing an overarching or synoptic units can ensure overall understanding. The assessment of achievement is independent of the particular models of learning.
For example, in practice the visible manifestation of units will be 'modules of delivery' - how the unit or units are 'taught'/delivered. There are various notional possible relationships between units, modules, and learning materials.
Units and modules can link 1 to 1, 1 to many, etc. There can be a many to many relationship between learning outcomes and:
Learning outcomes are seen as potentially freestanding (i.e., they may be independent of any awards scheme or delivery scheme), although in reality the relationships are likely to be established on the basis of developing professional and peer practice and emerging learner needs. What is important are the possibilities for creative and/or relevant program and course design etc.
A major benefit of this framework is that units can be of any size. The system of credit value (based on the notional learning time) means that units can vary in size. Small units will have a low credit value, larger units a higher value.
Each unit will also be ascribed a level. Therefore the framework can demonstrate:
- what a learner can do (learning outcomes)
- at what degree of difficulty/complexity/autonomy (level)
- how much (credit value)
The system therefore makes it possible to award learners credits based on the achievement of single units, combinations of units, and/or full qualifications. These can be shown on an individual learner profile or transcript. For example:
Unit A (credit value 2 level 1) 2 credits level 1
Unit B (credit value 3 level 2) 3 credits level 2
Unit C (credit value 8 level 3) 8 credits level 3
Thus learners can build up credits at different levels.
A3 - What the Framework Can Do
- Measures the level and volume of learning in an agreed and logical way.
- Presents the possibility of aggregating coherent and explicit sets of learning outcomes into units (of assessment).
- Offers a coherent way to maximize the effective use of technology for learning. For example it provides a model for disaggregating learning from accreditation.
- Undertake some learning using appropriate media and support, etc.
- Decide whether/when to go for accreditation for this piece of learning, and if so, to which award this will contribute.
- Prepare for the formal assessment for accreditation - e.g. by doing "practice tests".
- Collect all the evidence required for accreditation.
- Register for and be assessed for the accreditation.
(This would allow an awarding body to work towards near-100% success rate, and to encourage learners to be confident of success before registering.)
The framework described here has may uses across a range of educational purposes (for example):
A common format for learning outcomes and units of assessment would:
- Support technology-based delivery of learning.
- Allow accredited just-in-time learning.
- Link directly into the search for appropriate interoperable and reusable learning materials and assessments.
- Support individual learning styles.
- Motivate learners via incremental learning and interim accreditation.
- Provide clarity and consistency in the expression of learning outcomes.
- Help international harmonization and standardization.
- Be the basis for local, national, and international credit accumulation and transfer.
- Help materials developers, designers, providers, and purchasers to identify overlap and gaps in the market.
- Clarify and support guidance needed by learners.
- Provide a tool for mapping learning and achievement.
- Support evaluation and quality systems.
- Allow the creation of credit transcripts and records of achievement.
- Aid curriculum planning by states and institutions.
- Aid curriculum and qualifications design.
- Be a possible basis for funding education, training and learners.
- Aid parity of esteem for academic and vocational education and training.
- Be a universal performance/added value measure.
- Be a finer measure against individual, institutional and national education targets.
This section is based on a document by Kevin Donovan and Tony Tait, Development Advisers with the UK's Learning and Skills Development Agency, based in part on LSDA's work on a 'credit framework'.
Appendix B - Future Work
The scope of the 1EdTech Reusable Definition of Competence and Educational Objective is deliberately small to maximize the "reusable" aspect. The diverse applications described, whether related to learner or human resource process, etc. or in named specifications should be sufficient evidence that the scope of the RDCEO is usefully small.
It is clear, though, that there are applications where the RDCEO is not sufficient on its own and that there is a need for, but an absence of, interoperability specifications. Foremost is the need to be able to exchange the relationship information in a consistent way: taxonomies, equivalences, etc. Important too are processes of certification and accreditation. Other specification work might also be applicable to the RDCEO and lead to new best practices.
The Director of Specifications at 1EdTech Consortium (http://www.imsglobal.org/) welcomes contributions from the community of requirements, ideas, and pilot/research projects that might inform the scoping of future work.
About This Document
| Title | 1EdTech Reusable Definition of Competency or Educational Objective - Best Practice and Implementation Guide |
| Editors | Adam Cooper, Claude Ostyn |
| Team Leads | Dan Rehak, Claude Ostyn, Robby Robson |
| Version | 1.0 |
| Version Date | 25 October 2002 |
| Status | Final Specification |
| Summary | This document provides additional information regarding 1EdTech Reusable Definition of Competency and Educational Objective best practices and implementation guidelines. It is meant to complement the 1EdTech RDCEO Information Model and XML Binding documents. |
| Purpose | Defines best practices in the use of the 1EdTech Information Model for describing, referencing, and exchanging definitions of distributed learning competencies and educational objectives. |
| Document Location | http://www.imsglobal.org/competencies/rdceov1p0/imsrdceo_bestv1p0.html |
List of Contributors
The following individuals contributed to the development of this document:
Revision History
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Reusable Definition of Competency or Educational Objective - Best Practice and Implementation Guide ("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 Reusable Definition of Competency or Educational Objective - Best Practice and Implementation Guide Revision: 25 October 2002
