Sharebar?

IMS ePortfolio Best Practice and Implementation Guide Version 1.0 Final

IMS Logo

IMS ePortfolio Best Practice and Implementation Guide

Version 1.0 Final Specification

Copyright © 2005 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS/GLC
Document Name: IMS ePortfolio Best Practice and Implementation Guide
Revision: 02 June 2005

IPR and Distribution Notices

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

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

Copyright © 2005 IMS Global Learning 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 IMS found on the IMS website: http://www.imsglobal.org/license.html.

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

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

Please note that the British Standards Institute standard 8788, provisionally known as "UK Lifelong Learner Information Profile" and referred to in this specification, is under development by the BSI. For further information, please consult http://www.bsi-global.com/.


Table of Contents


1. Introduction
1.1 Structure of this Document
1.2 Nomenclature
1.3 References

2. Overview
2.1 ePortfolio Overview
2.1.1 Rationale
2.1.2 Business Requirements
2.1.3 Out of Scope
2.1.4 Intended Users
2.2 Structure of the Specification
2.3 Major Types of ePortfolios
2.3.1 Assessment ePortfolios
2.3.2 Presentation ePortfolios
2.3.3 Learning ePortfolios
2.3.4 Personal Development ePortfolios
2.3.5 Multiple Owner ePortfolios
2.3.6 Working ePortfolios
2.3.7 Out of Scope
2.4 Use Cases
2.4.1 Submitting an ePortfolio to an External Review System
2.4.2 Sharing an ePortfolio with Another ePortfolio System
2.4.3 Sharing an ePortfolio to Receive Feedback
2.4.4 Moving an ePortfolio Between ePortfolio Systems

3. Implementation Guidance
3.1 Using Core Data Structures
3.1.1 Owner
3.1.2 View
3.1.3 Relationship
3.1.4 Presentation
3.1.5 Accessibility
3.1.6 Affiliation
3.1.7 Assertion / Reflexion
3.1.8 Competency
3.1.9 Goal
3.1.10 Identification
3.1.11 Interest
3.1.12 Participation
3.1.13 Product
3.1.14 Qualification
3.1.15 Rubric
3.1.16 RubricCell
3.1.17 Security Key
3.1.18 Transcript
3.2 Other Implementation Information
3.2.1 Packaging
3.2.2 Grades
3.2.3 Multiple Owner ePortfolios
3.2.4 Importance Meta-data
3.2.5 Advice on Referencing Portfolios and PortfiolioParts
3.2.6 Comments

4. Extended Examples
4.1 Minimal Example
4.2 Reflexion and Assertion Example
4.3 Views and Style Example

5. Implementation
5.1 Mapping of learndirect ePortfolio Data to IMS ePortfolio Specification
5.1.1 Binding and Packaging

6. Conformance
6.1 Import Definition
6.2 Export Definition

About This Document
List of Contributors

Revision History

Index


1. Introduction

This document is a part of the IMS ePortfolio specification. This document provides non-normative guidance on how to use the Binding and Information Model. For a conceptual overview of the ePortfolio Specification, please see section 1 of the Information Model [EP, 05a]. For a discussion of how the ePortfolio Information Model should be represented using XML schema and the IMS Content Packaging specification, see the XML Binding [EP, 05b].

1.1 Structure of this Document

The structure of this document is:

2. Overview The description of the rationale for the specification, the major types of ePortfolios, use cases, and examples.
3. Implementation Guidance The description of the core data structures and implementation suggestions.
4. Extended Examples Some example ePortfolios.
5. Conformance The description of the conformance definition.

1.2 Nomenclature

CSS Cascading Style Sheets
NLII EDUCAUSE National Learning Infrastructure Initiative
W3C World Wide Web Consortium
XML Extensible Mark-up Language
XSD XML Schema Definition
XSL Extensible Stylesheet Language
XSLT XSL Transformations

1.3 References

[EP, 05a] IMS ePortfolio Information Model v1.0, D.Cambridge, C.Smythe, M.McKell, IMS/GLC, June 2005.
[EP, 05b] IMS ePortfolio XML Binding v1.0, D.Cambridge, C.Smythe, M.McKell, IMS/GLC, June 2005.
[RUBRIC, 05] IMS Rubric Specification v1.0, A.Cooper, C.Smythe, M.McKell, IMS/GLC, June 2005.
[ACCG, 02] IMS Guidelines for Developing Accessible Learning Whitepaper v1.0, IMS/GLC, June 2002.
[ACCLIP, 03] IMS Learner Information Package Accessibility for LIP v1.0, M.Norton, J.Treviranus, IMS/GLC, June 2003.
[ACCMD, 04] IMS AccessForAll Meta-data v1.0, A.Jackl, IMS/GLC, July 2004.
[BUND, 01] Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications, v1.0, B.Olivier, M.McKell, IMS/GLC, August 2001.
[CP, 04] IMS Content Packaging, v1.1.4, C.Smythe, A.Jackl, IMS/GLC, October 2004.
[ES, 04] IMS Enterprise Services v1.0, C.Smythe, IMS/GLC, July 2004.
[LIP, 01] IMS Learner Information Package v1.0, C.Smythe, F.Tansey, R.Robson, IMS/GLC, March 2001.
[LIP, 05] IMS Learner Information Package Summary of Changes v1.0.1, C.Smythe, IMS/GLC, January 2005.
[RDCEO, 02] IMS Reusable Definition of Competency or Educational Objective v1.0, A.Cooper, C.Ostyn, IMS/GLC, October 2002.
[VDEX, 04] IMS Vocabulary Definition Exchange v1.0, A.Cooper, IMS/GLC, February 2004.

2. Overview

2.1 ePortfolio Overview

2.1.1 Rationale

The use of ePortfolios in distributed learning in compulsory and higher education worldwide has increased dramatically over the last five years. While ePortfolios previously took the form of static Web pages, the growth over the last few years has been fueled by the growing availability of commercial and open source ePortfolio tools in the form of database-driven, Web applications. Currently available systems, known to the IMS ePortfolios Development Committee, store ePortfolios in formats that do not reflect accepted open standards, and have no facilities for importing and exporting ePortfolio information conformant with accepted standards. This makes it difficult or impossible to move ePortfolios intact between systems, and leads to inefficiency and redundancy when integrating ePortfolio tools with other enterprise systems.

In addition to being used in particular courses, ePortfolios are increasingly being used across whole programs and institutions. ePortfolios are beginning to be used as tools for personal development planning, lifelong learning, and learning in the workplace. ePortfolios are also beginning to be used for high-stakes assessment and credentialing.

ePortfolios need to be portable to ensure the educational continuity between programs within an educational institution that use ePortfolios, the integration of evidence about learning over time, and the smooth transfer of verifiable information about learning and evaluation between institutions, levels of education, and employers. From an individual perspective, information about and artifacts of a person's performance and achievement, as recorded in an ePortfolio, need to operate across institutions and countries throughout their lifetime.

2.1.2 Business Requirements

The EDUCAUSE NLII defines an ePortfolio as "a collection of authentic and diverse evidence, drawn from a larger archive, that represents what a person or organization has learned over time, on which the person or organization has reflected, designed for presentation to one or more audiences for a particular rhetorical purpose." The "larger archive" may contain multiple views of its contents directed towards multiple audiences. This collection usually takes the form of a set of pieces of evidence of learning and performance, reflections or interpretations on that evidence, and representations of relationships between and among the evidence, interpretations, and evaluation criteria. Broadening out from just learning, an ePortfolio could also evidence personal qualities and attributes, or any "competencies" that are relevant to the particular audience, who could be potential employees or colleagues interested in performance at work, as well as academics interested in the outcomes of learning.

The subject of the ePortfolio may also be the same person as the audience, and the purpose may be reflection. In this case, there are no particular bounds to what is relevant, and the whole of the archive can be considered to be the ePortfolio. While the subject of an ePortfolio is always the overall owner of the portfolio, some evidence, reflections, relationships, and criteria may have been created and may be owned by another individual or group. The authenticity and integrity of these parts may need to be verifiable with some third-party authority.

This expanded version of the NLII definition describes the most complicated and sophisticated structure of ePortfolios found in practice. In many concrete applications, certain elements may be unnecessary. Many ePortfolios contain only a single view. Some ePortfolios contain only parts owned and authored by their subject. Some ePortfolios contain no reflections, while others contain no assessment information. Some contain information about how to render their contents, while some do not. This specification provides the means to represent both complex and simple ePortfolio types.

2.1.2.1 Parts to be Included and Excluded from the Scope of ePortfolio

The overall scope of the uses mentioned herein suggests that an ePortfolio archive, or a general ePortfolio, might contain, in addition to actual packaged digital works, these different kinds of information:

  • about digital and non-digital works created or part-created by the subject;
  • about the subject of the e-portfolio;
  • about activities in which the subject has participated, is participating, or plans to participate;
  • about the competencies (skills, etc.) of the subject;
  • about the achievements of the subject, whether or not certificated;
  • about the subject's preferences;
  • about the subject's goals and plans;
  • about the subject's interests and values;
  • any notes, reflections or assessments relevant to any other part;
  • the results of any test or examination of the subject;
  • contextual information to help the interpretation of any results;
  • the relationships between the other parts of the information (see elsewhere for discussion);
  • about the creation and ownership of the parts of the ePortfolio.

This list is intended to be inclusive and indicative but not exhaustive, and does not in any way prescribe mandatory contents or structure to any ePortfolio.

2.1.3 Out of Scope

2.1.3.1 ePortfolio Services

ePortfolio services and behaviors are explicitly out of scope for this specification document.

2.1.3.2 Storage of ePortfolio information

Nothing in this specification should be taken to imply any particular arrangements for storage of ePortfolio information. Any kind of ePortfolio could be virtual, in the sense that the information could be held in different places on different systems, and brought together only at the time of viewing. Virtual data rendered real-time in an ePortfolio would need to be saved in some manner within the ePortfolio as part of the ePortfolio packaging process.

2.1.4 Intended Users

The intended users of this specification are software developers designing ePortfolio tools, developers integrating other systems with ePortfolio tools, and developers of e-learning tools that incorporate ePortfolio-related functionality.

2.2 Structure of the Specification

The ePortfolio specification is comprised of the following documents, each with distinct scope:

Information Model

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). There are many possible bindings of the Information Model but at the current time the only specified binding is to XML.

Because many of the data types used to define an ePortfolio are described in existing specifications and standards, this Information Model does not replicate these definitions. Instead, readers are referred to the Binding document to see how the concepts described in the Information Model should be realized.


XML Binding

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 or by declaration of the namespace reserved by the specification. In cases of error or omission, the Information Model takes precedence. The ePortfolio XML Binding is accompanied by a set of control documents using the W3C Schema Language to be used in implementations.


Best Practice and Implementation Guide (this document)

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 IMS specifications. Implementers are encouraged, by not required, to follow guidance in this part of the specification. The ePortfolio Best Practice and Implementation Guide is accompanied by a set of example XML files that conform to the XML Binding.


Rubric Specification

Contains the portions of the ePortfolio Specification focused on rubrics. The Rubric Specification provides a normative description of the core aspects of the specification and includes a binding of that description to XML version 1.0 that is normative for any XML instance that claims to use it. The Rubric Specification is accompanied by a control document using the W3C Schema Language to be used in implementations. It is also released with an example XML file that conforms to the Rubric Specification.

2.3 Major Types of ePortfolios

2.3.1 Assessment ePortfolios

Assessment ePortfolios are used to demonstrate achievement to some authority by relating evidence within the ePortfolio to performance standards defined by that authority. Rubrics are commonly used to score assessment portfolios. For example, nursing students at a university might be required to submit an assessment ePortfolio that presents evidence that they have a set of competencies defined for nurses in their country as a graduation requirement. Departments or schools may use assessment ePortfolios for accreditation purposes.

2.3.2 Presentation ePortfolios

Presentation portfolios are used to evidence learning or achievement to an audience in a persuasive way. Presentation portfolios often contain instructions about how their contents should be rendered. Presentation portfolios are often used to demonstrate professional qualifications. For example, a software engineer might create a presentation ePortfolio that incorporates and shows the relationships between professional certifications she has received, code she has written, and her employment history in order to convince a potential employer to hire her. Faculty members might use presentation ePortfolios to collect materials for tenure track review purposes.

2.3.3 Learning ePortfolios

Learning ePortfolios are used to document, guide, and advance learning over time. They often have a prominent reflective component and may be used to promote metacognition, to plan learning, or for the integration of diverse learning experiences. Learning ePortfolios are most often developed in formal curricular contexts. For example, a secondary school students might be asked to develop a learning ePortfolio that tracks and allows them to reflect upon how their technology skills improve over the course of a year.

2.3.4 Personal Development ePortfolios

Personal development planning is defined in the UK as "a structured and supported process undertaken by an individual to reflect upon their own learning, performance and / or achievement and to plan for their personal, educational and career development." Thus, an ePortfolio for personal development planning contains records of learning, performance, and achievement which can be reflected on, and outcomes of that reflection, including plans for future development. This could include a learning ePortfolio, but goes beyond that, as it is often related to professional development and employment, so also possibly used as a presentation ePortfolio.

2.3.5 Multiple Owner ePortfolios

Multiple Owner ePortfolios are used to allow more than one individual to participate in the development of content and presentation. A multiple owner ePortfolio might combine elements of the above portfolio types, but most likely takes the form of a Presentation ePortfolio when used for such purposes as a website or group blog and a Learning ePortfolio when used by a group of learners to present evidence of their academic growth through the group collaboration. Multiple Owner ePortfolios are often used to represent the work and growth of an organization or organizational unit and, when so employed, may by referred to as program or institutional portfolios.

2.3.6 Working ePortfolios

Working ePortfolios combine elements of all of the proceeding types. They often include multiple views, each of which may be analogous to an assessment, presentation, learning, or development ePortfolio. In the terms of the NLII definition, a working portfolio is the larger archive from which the contents of one or more ePortfolios may be selected. The whole of a working ePortfolio is generally accessible only to its subject, while views are made accessible to other individuals and groups.

2.3.7 Out of Scope

Unless there are specific reasons for including it, to the benefit of the subject and agreed by the subject, ePortfolio information would not normally include: medical records; financial records; government records including criminal and statutory records; nor records made by other parties of the subject's dealings with them.

2.4 Use Cases

The use cases below are intended to illustrate some common scenarios leading users to package their ePortfolio. Each scenario contains one sample use case. These use cases are not intended to be comprehensive of every use case associated with the packaging scenario.

2.4.1 Submitting an ePortfolio to an External Review System

Narrative:
A student is enrolled in a program of study in preparation to enter a profession. The curriculum maps with certification and accreditation requirements for that profession and requires each student to submit an ePortfolio demonstrating their completion of these requirements to an institutional assessment system prior to graduation. The student has collected evidence of her performance and mapped the evidence to the standards in a personal ePortfolio tool. She uses the tool to send a view of her ePortfolio that includes all the necessary information to the program's assessment system. The system ingests the ePortfolio with the mappings between evidence and standards intact.

Primary Actors: Learner, Instructors, Administrators

Stakeholders and Interests:

  • Student - a pre-service professional uses an ePortfolio to demonstrate competency and apply for professional certification.
  • Program faculty - use the ePortfolio to assess competencies of students within their program of study.
  • Program Administrators - compile and share ePortfolio evidence with accreditation organizations.
  • Certification Organizations - require valid methods for certifying applicants.

Preconditions:

  • The student has enrolled in a professional program of study.
  • The program of study delivers a curriculum that engages learners in a range of activities that provide students with the opportunity to demonstrate basic levels of competency as defined by the professional authority in the field.
  • The student has completed the activities established by the program.
  • During the completion of the activities, the student has assembled an ePortfolio by collecting and reflecting upon evidence of learning within a personal ePortfolio tool.
  • The student has selected a subset of the evidence and mapped it to the standards defined within the program's curriculum.

Trigger:
Upon completion of the program of study, the student instructs his ePortfolio tool to send the view of his ePortfolio to the institutional system.

Main Success Scenario:

  • The personal ePortfolio tool exports a copy of the view, including all evidence and the relationships between parts of the elements and between elements and standards.
  • The personal ePortfolio tool sends the view to the institutional system.
  • The institutional system imports the view, including all the evidence, relationships, and standards.
  • The institutional system maps the evidence and relationships to standards already represented within the system.

Alternative Path:

  • After the ePortfolio tool exports a copy of the view, the student stores it on removable media and sends it to a faculty member.
  • The faculty member instructs the institutional system to import the view.

2.4.2 Sharing an ePortfolio with Another ePortfolio System

Narrative:
A professional employee is required to participate in, keep track of, and annotate professional development training experiences as part of his employment with his organization. As a part of his plan, he enrolls in a graduate level program in pursuit of an advanced degree. The graduate school also requires students to develop online portfolios of their graduate school work. The ePortfolio tools being used by the organization and the graduate school are different systems. Rather than reproduce the same work for both systems, the learner should be able to export and import work samples and ePortfolio evidence back and forth from both systems in order to efficiently comply with both organizations' educational requirements.

Primary Actors: Learner, Instructors, Administrators

Stakeholders and Interests:

  • Learner - uses an ePortfolio to record and reflect upon the mastery of stated learning objectives for training or graduate school.
  • Instructor - uses ePortfolio to access the development of students throughout a period of learning.
  • Personnel Supervisors - compile and review ePortfolio professional development evidence from employees as part of personnel review procedures.

Preconditions:

  • The learner has enrolled in a course of study that requires ePortfolio development.
  • The learner is employed in an organization that tracks professional development.
  • The course of study delivers a curriculum that engages learners in a range of activities that provide students with the opportunity to collect and reflect upon the learning that takes place related to stated learning objectives.
  • Some of these learning objectives may or may not match the professional goals required by the employing organization.
  • As a part of their participation in the learning/professional development process, the student assembles an ePortfolio by collecting and reflecting upon evidence of learning related to the stated learning objectives within a personal ePortfolio tools.

Trigger:
At critical junctures within a program of study defined by user, the user reviews his learning ePortfolios and updates one ePortfolio system from another.

Main Success Scenario:

  • The school ePortfolio tool exports a copy of the view, including all evidence and the relationships between parts of the elements and between elements and learning objectives.
  • The learner instructs the school ePortfolio tool to send the view to the employer's ePortfolio system.
  • The employer's ePortfolio system imports the view, including all the evidence, relationships, and objectives.
  • The employer's ePortfolio system maps the evidence and relationships to professional development goals represented within the system.

Alternative Path:

  • After the ePortfolio tool exports a copy of the view, the student stores it on removable media and sends it to the employer's system administrator.
  • The system administrator directs the system to import the view.

2.4.3 Sharing an ePortfolio to Receive Feedback

Narrative: Government policy requires that all students enrolled in a higher education program receive support for their general education outside of the context of a particular course. Students collect information about their general-education-related learning and performance and reflect upon it using a personal ePortfolio tool. Periodically, they share a subset and presentation of this information with advisors, counselors, and faculty members at their institutions by exporting this view to the institution's ePortfolio system. The audience for the ePortfolio reads and provides feedback on the ePortfolio using the institutional system.

Primary Actors: Learner, Instructors, Administrators

Stakeholders and Interests:

  • Student - uses an ePortfolio to record and reflect upon the mastery of stated learning objectives.
  • Instructor - uses ePortfolio to access the development of students throughout a period of learning.
  • Program Administrators - compile and review ePortfolio evidence from program graduates as part of program evaluation.

Preconditions:

  • The student has enrolled in a course of study.
  • The course of study delivers a curriculum that engages learners in a range of activities that provide students with the opportunity to collect and reflect upon the learning that takes place related to stated learning objectives.
  • As a part of their participation in the learning process, the student assembles an ePortfolio by collecting and reflecting upon evidence of learning related to the stated learning objectives within a personal ePortfolio tool.

Trigger:
At critical junctures within a course of study defined by instructor, the instructor reviews the learning ePortfolio of a student in the course.

Main Success Scenario:

  • The personal ePortfolio tool exports a copy of the view, including all evidence and the relationships between parts of the elements and between elements and learning objectives.
  • The personal ePortfolio tool sends the view to the instructor.
  • The instructor imports the view, including all the evidence, relationships, and objectives.
  • The instructor's system maps the evidence and relationships to learning objectives already represented within the system.

Alternative Path:

  • After the ePortfolio tool exports a copy of the view, the student stores it on removable media and sends it to the instructor.
  • The instructor directs the system to import the view.

2.4.4 Moving an ePortfolio Between ePortfolio Systems

Narrative:
A user moving from one institution to another should be accompanied with as complete a transfer of all ePortfolio materials as possible. For example, a graduating high school student should be able to transfer all of her ePortfolio materials from her secondary school to the college she will be attending. The student has developed several views of her work for different audiences which link to specific work within the working ePortfolio. In some systems, users can store additional ePortfolio materials not linked to a view. It is important to retain these materials as part of the user's working ePortfolio. All of these materials and the relationships between these should be transferred from one ePortfolio system to the next. This same type of complete transfer should also occur when a student moves from one college to another or from college to graduate school. The same type of transfer should also occur for other user types such as instructors moving from one school to another, or professionals moving from one organization to another.

Primary Actors: Author, Administrator

Stakeholders and Interests:

  • Author - transport ePortfolio from one environment to another-possibly the same ePortfolio application, but likely another vendor application. Common scenarios: student from one college to another, student from high school to college, student from college to graduate school, instructor from one institution to another.
  • System Administrators - support ePortfolio lifecycle longer than the user's experience on their system. Users must be able to export their ePortfolios when they leave the system. Users expect to bring ePortfolios from another system (regardless of the application platform) to the current system the administrator supports.

Preconditions:
The author has assembled an ePortfolio of any type.

Trigger:
The primary author creates an export package of the ePortfolio.

Main Success Scenario:

  • The personal ePortfolio tool generates an export package for the user's ePortfolio based on user action. This package contains identification and the contents of the ePortfolio. Other data types and information about the relationship of the data types is included as appropriate.
  • The user imports this ePortfolio package onto the destination system.
  • The destination system reads the ePortfolio package and generates a new ePortfolio on the system. Note: the success of data mapping between systems will vary greatly.

Alternative path:

  • The user exports the ePortfolio for archival purposes or viewing outside of an ePortfolio system.
  • The personal ePortfolio tool generates an export package for one or more users' ePortfolios based on administrator action.

3. Implementation Guidance

3.1 Using Core Data Structures

In order to ensure consistency through future revision and to minimize duplication, this specification relies on the LIP Best Practice Guide [LIP, 01] definitions for core data structures wherever possible. In some cases, those definitions do not sufficiently describe the data element. Where that is true, new definitions are provided below.

3.1.1 Owner

The owner of a portfolio should be indicated through the use of the LIP <identification> element. This element allows for a portfolio to be identified with an individual, several individuals, or an organization by using the <formname> and <name> elements of that structure multiply. Every portfolio should have one or more owners implemented as one identification record.

3.1.2 View

Multiple views may be defined within a portfolio through the use of multiple presentations.

3.1.3 Relationship

The relationships between the different elements of the ePortfolio are an important component of the meaning and significance of the material. In some cases it would be difficult, or even impossible, to understand what the elements mean without the relationship information. The <relationship> element represents these relationships.

The principle recommended relationships are primarily intended to be used as one-to-one relationships. Some of them can also be used as one-to-many relationships. A single one-to-many relationship with N destination elements is exactly equivalent to N one-to-one relationships identical except in their destination.

Table 3.1 represents a view of some of the relationships which might be useful to represent. The relationship types described are recommended provisionally, prior to feedback from experience in use.

Table 3.1 Some relationships between ePortfolio elements.

destination Activity Competency Goal Interest Product Qcl Assertion, Reflexion
Activity is part of, precedes evidences, shows up, supports supports evidences supports supports, supplements
 
Affiliation supports supports supports
 
supports supports
 
Competency evidences, supports, precedes is part of, precedes supports evidences supports supports
 
Goal
 
aims at supports, precedes
 
aims at aims at
 
Interest supports supports supports is part of, precedes supports supports supports
Product evidences, supports evidences, shows up supports evidences supports,
is part of, precedes
supports
 
Qcl evidences, supports evidences supports evidences supports supports
 
Assertion attests, evaluates, presents Attests, presents attests, evaluates, presents attests, evaluates, presents attests, evaluates, presents attests, evaluates, presents attests, evaluates, presents
Reflexion evaluates, reflects on reflects on evaluates, reflects on evaluates, reflects on evaluates, reflects on evaluates, reflects on evaluates, precedes, reflects on

3.1.3.1 <typename>

Every <relationship> element should have a type, chosen from a controlled vocabulary, represented in the <typename> element. Table 3.1 introduces a set of relationship types that could serve as the basis for such a controlled vocabulary. They are further explicated below.

AimsAt
Where a goal is closely associated with the achievement of a specific competency, with the creation of a product, or with the attainment of qualification or other achievement, and where the associated item is separately defined in its own element, a relationship of type "AimsAt" should be used with the goal as source and the other element as destination. The goal can include other information not represented in the <competency>, <product>, or <qcl> element, such as target date of completion. Typically, any activities that support a goal which aims at one of these things can also be represented as supporting that same thing.

Attests
Where a piece of text, or document, is represented as an assertion, and constitutes a confirmation that something represented in the ePortfolio is true, or states what it is about that element that can be attested as true, this should be represented in a relationship of type "Attests" between the assertion as source and the element or elements as destination. This can be much like a testimonial: the relationship links appropriate testimonial material to the ePortfolio elements they attest. It can be created by anyone, including the subject.

Claims
Where a piece of writing, represented as an assertion, explains the force or quality of a relationship of type "Evidences", this should be represented in a relationship of type "Claims" between the assertion as source and the relationship as destination, e.g., an assertion written by a mentor: "This group activity is good evidence of N's teamwork skills in that ..." The level of the competency claimed should not be represented within the <relationship> element, but the competency claimed should itself contain information about its own level.

Evaluates
Where something is written with the intention of evaluating something else, whether by the subject or by someone else, this should be represented in a relationship of type "Evaluates" between the <reflexion> or <assertion> which expresses the evaluation as source, and the element evaluated as destination. A competency should not be the destination of a relationship of type "Evaluates". Essentially an evaluation can state how good, bad, or suitable something is given its context or purpose.

Evidences
A relationship of type "Evidences" should be used: firstly, where an <activity>, <product>, or <qcl> element, as the source of the relationship, is considered as evidence for a competency of the subject, as destination; secondly, where one element, as source, is regarded as evidence of the truth of another element, as destination; thirdly, where an <activity>, <product>, or <qcl> element, as source, is considered as indirect evidence of an interest, as destination; and fourthly, where a <competency> or <qcl> element, as source, gives evidence for the level to which the interest, as destination, has been taken.

IsPartOf
A relationship of type "IsPartOf" should be used to represent the fact that one element, as source, is part of another element as destination.

Precedes
A relationship of type "Precedes" should be used to note that the fact represented by one element actually precedes another.

Presents
A relationship of type "Presents" should be used where an assertion, as source, represents any other particular element, as destination, in a way designed for presentation to a particular audience and a particular purpose. This kind of presentation could be done ad hoc, but having this relationship allows the storage of a particular presentation of another element, so that it can be reused. If a product is used to present another element, an assertion can be used as an intermediary representation, referring to the product.

ReflectsOn
A relationship of type "ReflectsOn" should be used where a <reflexion>, as source, is related to any other element, as destination, and where no other relationship expresses any more specific relationship. The <reflexion> can either simply be the product of the subjects reflective activity, or it can be explanatory in any other general way. Such a <reflexion> might be created by anyone, in which case it would be the <reflexion>, more than its creator, which would be seen as reflecting on the target element.

ShowsUp
A relationship of type "ShowsUp" should be used where any element, as source, is evidence of a perceived need to improve a particular competency, as destination. An assertion and a "Claims" relationship can be used to explain the way that the source and destination of a "ShowsUp" relationship are related, in the same way they can for elements related by an "Evidences" relationship. This can be useful in personal development planning.

Supplements
A relationship of type "Supplements" should be used at most once for each <qcl> element, instead of the "Supports" relationship, to relate a single <activity> element, as source, to the <qcl> element, as destination, where the <activity> element represents the overall educational program which leads to the award of the qualification represented in the <qcl> element. This enables information about the educational program to be clearly and unambiguously associated with the qualification etc. This is useful in the context of a European Diploma Supplement or similar documentation.

Supports
A relationship of type "Supports" should be used to represent any causal or supposedly causal relationship between two elements, irrespective of the strength or necessity of that relationship, with the causative element as source and the caused element as destination. Relationships such as "contributes to", "helps with" or "is a prerequisite of" are included in this. It is put in just one category because of the difficulty of making clean separations between different categories of causal relationship.

The Open Source Portfolio 2.5 specifications include two additional relationship types:

Uses - A relationship of type specifies a dependency between elements.

IsVersionOf - A relationship of type is IsVersionOf of indicates that two elements are different version of the same item. The direction of the relationship indicates which version is most recent. This is important in ePortfolios designed to show change over time through tracking revision of samples of work.

3.1.3.2 <tuple>

There should be exactly one <tuple> element in any <relationship>.

The <tuplesource> and <tupledest> elements of the tuple should hold the indexid elements given in the referential element of the <contentype> element of the appropriate elements in the ePortfolio. They should only have sourcedid elements if it is required to make a relationship whose destination is not part of the same learner's ePortfolio.

The <tuplerelation> element of the tuple is required by the IMS LIP 1.0 specification, but the specified use is already satisfied by the <typename> element of the relationship. It can be left empty, or any text can be contained, which may be ignored by other systems. Alternatively, a controlled vocabulary can be used in the <typename> element of the <tuplerelation>, perhaps to represent the logical characteristics of a relationship that are likely to affect the way it is to be processed automatically.

The IMS VDEX v1.0 specification [VDEX, 04] should be used to respresent controlled vocabularies.

3.1.3.3 <description>

The <description> element should be used to give supplementary information about a relationship. It should neither be used to substitute for the <typename> element, nor to hold any information which could be held within the related elements.

If the length of the description is less than 255 characters, it should be given in the <short> element. If the description is longer than 255 characters, a summary of less than 255 characters should be given in the <short> element, and the description in the <long> element.

Examples:

<relationship>
   <typename>
      <tysource sourcetype="standard">ePortfolio</tysource>
      <tyvalue>Supplements</tyvalue>
   </typename>
   <contentype>
      <referential>
         <indexid>relationship_01</indexid>
      </referential>
   </contentype>
   <tuple>
      <tuplesource>
         <sourcedid>
            <source>ePortfolio_Example</source>
            <id>1001</id>
         </sourcedid>
         <indexid>activity_01</indexid>
      </tuplesource>
      <tuplerelation>
         <text>results_in</text>
      </tuplerelation>
      <tupledest>
         <sourcedid>
            <source>ePortfolio_Example</source>
            <id>1001</id>
         </sourcedid>
         <indexid>qcl_01</indexid>
      </tupledest>
   </tuple>
   <description>
      <short>The detailed transcript for an awarded qualification</short>
   </description>
</relationship>

3.1.4 Presentation

The Presentation class represents a specification for the presentation of the Portfolio, including the selection and ordering of items from the set of available PortfolioParts and their constituent attributes. The order of multiple <item>s is indicative of the order of presentation.

Methods of implementing presentations may be different for different technologies. Where a Content Package is being processed, XSLT is an appropriate filtering technology and an XSLT for printing, possibly accompanied by XSLT-FO instructions, may be provided. For runtime browser interpretation, CSS stylesheets may be provided. Where the ACCLIP (see sub-section 3.1.5) of the audience is known this may be used in generating style files appropriate to that ACCLIP. Implementation of views will receive more detailed treatment in a future version of the specification.A means to specify that presentation is essential to a particular view (the view is for human interpretation) may be provided in this or a future version of the specification.

3.1.5 Accessibility

The Accessibility class describes data that implements the functional accessibility preferences of the portfolio owner in accordance with the specification IMS Accessibility for LIP [ACCLIP, 03]. That specification describes a data model for recording a user's preferences for how material is displayed, how a user interacts with and controls a system and specific accessibility properties the user requires of content. There is an associated specification IMS AccessForAll Meta-data [ACCMD, 04] that describes meta-data for the labeling of content for accessibility. These specifications can be used together, with fields being matched between the two specifications to select content a user can use, and ACCLIP alone being used to customize content and provide information necessary for interface customization (such as browser switches) and on-the-fly content adjustment. This is similar to views.

An ACCLIP instance can contain multiple contexts, each of which can be a complete set of preferences for some particular circumstances. ACCLIP instances should be editable. There are several implementation/best practice considerations:

  • An ePortfolio can provide a place for users to keep their ACCLIP.
  • To be accessible to some particular user an ePortfolio system may need to adjust its own interface and the way it presents and renders content.
    For example, a blind user is likely to be using some particular screen-reader when using the system. A system will need to consult the owner's ACCLIP and make whatever adjustments are necessary to operate in the environment that user requires according to the selected ACCLIP/Context (to work with that particular screen-reader). Where content has suitable meta-data identifying its accessibility aspects (as defined in the ACCMD specification) then some selection or on-the-fly adjustment of content may be required. For example, where content has alternative forms it may be necessary to select a suitable form to match ACCLIP fields. A very common example is presenting text instead of images.
  • The audience for whom a view is being prepared may not be the user with the stored ACCLIP and that audience's ACCLIP may not be available at view-construction time.
    Wherever possible content should be authored for the widest accessibility. Appropriately designed authoring tools can facilitate this. The recommendation here is to seek guidance at system and tool design time from the IMS Guidelines for Developing Accessible Learning Applications [ACCG, 02].
  • An organization can have an ACCLIP that defines a house style, such as particular fonts etc.
  • ACCLIPs can cascade. For example, there may be an organizational ACCLIP for the system or some group of users, and then an individual user's ACCLIP may need to over-ride that in order to make the content or system accessible for that user.

3.1.6 Affiliation

The <affiliation> element can be used to store the description of an organization affiliation associated with the Owner of the ePortfolio e.g., professional memberships.

This element can be represented using the XML binding of the Affiliation structure as defined in the IMS Learner Information Package specification. [LIP, 01].

3.1.7 Assertion / Reflexion

The <reflexion> and <assertion> elements are structurally equivalent, and contain textual materials relevant to the other elements in the ePortfolio, in cases where there is no adequate provision within other existing element elements, such as their description elements.

Materials or text within <description> elements of other elements need to relate entirely to the containing element which they describe. However there are occasions where something is written that refers to more than one other element of the ePortfolio, or where the role of the written material is not descriptive. In these cases a description within another element is not adequate, and a <reflexion> or <assertion> element should be used instead.

The main category of <reflexion> element is when the subject reflects on anything which can be represented or recorded in other elements of the ePortfolio. The product of reflection is not generally the same as a straightforward description. The <reflexion> element can then hold the product of that reflection. The related reflective practice is seen to be highly important in programs of education and personal development. The <reflexion> elements created in this way can then be related to the objects of reflection through <relationship> elements.

An <assertion> element is used to represent text or material that is relevant to something else within the ePortfolio and is not a product of reflection. This could be a testimonial, or just a comment from a witness, mentor, or colleague.

Particular uses of <assertion> elements include: claiming competency; attesting another element; presenting any other element; recording an agreement.

3.1.7.1 <typename>

The following is is not an exclusive list of typenames; types should be drawn from whatever controlled vocabulary is being used.

An <assertion> element should be represented with type "Agreement" if its main purpose is to hold an agreement.

An <assertion> element should be represented with type "Note" if it is a general note with no other relevant type, and is not related to other elements of the ePortfolio.

An <assertion> element should be represented with type "SelfPresentation" if it is a personal statement or other similar composition which expresses the position of the subject at a particular time.

A <reflexion> or <assertion> element should be represented with type "ContextDefined" if its context and function is represented adequately by the relationships in which it participates.

A <reflexion> or <assertion> element should be represented with type "Strengths" if its main purpose is to express one or more competencies possessed by the subject.

A <reflexion> or <assertion> element should be represented with type "Valuation" if its main purpose is to evaluate some other element of the ePortfolio.

A <reflexion> or <assertion> element should be represented with type "Weaknesses" if its main purpose is to express the competencies that are seen as lacking with respect to a particular activity or goal, to which the element should be related.

A <reflexion> element should be represented with type "Anticipation" if its main purpose is to represent reflections of the subject in anticipation of a future element of the ePortfolio such as an activity.

A <reflexion> element should be represented with type "Aspect" if it serves to reflect on a certain aspect of one or more elements of the ePortfolio.

A <reflexion> element should be represented with type "Retrospection" if its main purpose is to represent reflections of the subject after another element of the ePortfolio, such as an activity, has occurred.

3.1.7.2 <authorship>

The <authorship> element should express the authorship of the <reflexion> or <assertion>, e.g., a referee where the assertion is a testimonial; the assessor where the assertion evaluates another element of the ePortfolio; the joint authors of an agreement; authorship by one person and editing by another; automatic generation. If the <authorship> element is not present, the author is assumed to be the subject of the ePortfolio.

3.1.7.3 <rationale>

A <reflexion> or <assertion> can have any number of <rationale> elements. The rationale should represent the intended audience of the <reflexion> or <assertion> element, and should explain its intended significance to that audience. This should provide element of the context of the reflection or assertion, and help a reader in interpretation and comprehension. If no rationale is given, the audience should be understood to be the subject, and the purpose should be understood to be similar to a log, diary, or journal. Rationales can be added or modified after the time of creation of the reflection or assertion.

3.1.7.4 <date>

A <date> of type "Create" should be used to represent the date on which the <reflexion> or <assertion> was first composed.

A <date> of type "Update" should be used to represent the date on which the <reflexion> or <assertion> was revised. This is not the same as the date on which the revised record was stored in the record system, which can be recorded in the temporal meta-data.

A <date> of type "Reference" should be used to represent any date which forms the context of the <reflexion> or <assertion>, i.e. a date on which any events reflected on or attested actually took place.

A <date> of type "Publish" should be used to represent a date on which the <reflexion> or <assertion> was published or made generally available to the public.

3.1.7.5 <status>

A <status> of type "Draft" should be used to qualify a <reflexion> or <assertion> which is being worked on, where the author is not yet satisfied that it represents what is intended.

A <status> of type "Completed" should be used to qualify a <reflexion> or <assertion> which has been finished, where the author is satisfied that it represents what is intended.

A <status> of type "Expired" should be used to qualify a <reflexion> which is no longer relevant due to changes that have happened since it was written.

3.1.7.6 Relationships Involving Reflections or Assertions

Relationships are vital to the full representation of the context and significance of <reflexion> and <assertion> elements. In the following cases, the <reflexion> or <assertion> element is the source of the relationship, and the other element the destination.

A <relationship> of type "Attests" should accompany an <assertion> element which is intended to certify of any other element of the ePortfolio.

A <relationship> of type "Evaluates" should accompany a <reflexion> or <assertion> element where the element serves to evaluate any other element of the ePortfolio, e.g., an observer giving an assessment of how well a certain activity was performed.

A <relationship> of type "Presents" should accompany an <assertion> element whose purpose is to express any element of the ePortfolio in words suitable for a particular audience and purpose.

A <relationship> of type "ReflectsOn" should accompany any <reflexion> element which relates to any element of the ePortfolio in a way not covered by other relationships.

Where there is a <relationship> of type "Evidences" between any elements of the ePortfolio and a competency, and an <assertion> element explains the way in which the other element serves as evidence of the competency, that <assertion> element should be the source of a relationship of type "Claims", with the evidential relationship as destination.

3.1.7.7 Examples

<assertion>
   <contentype>
      <referential>
         <indexid>assertion_01</indexid>
      </referential>
   </contentype>
   <authorship>Dr. A. Brown (tutor)</authorship>
   <rationale>A witness statement relating to group assignment</rationale>
   <date>
      <typename>
         <tysource sourcetype="standard">ePortfolio</tysource>
         <tyvalue>Create</tyvalue>
      </typename>
      <datetime>2004-05-31T12:25:43</datetime>
   </date>
   <description>
      <short>Michael Short's group work</short>
      <long>I supervised the group assignment on UML modelling.
      Michael related well to the rest of his group, displaying significant
      leadership potential. He initiated task-oriented communications
      and played an active role in conflict resolution.
      Overall, I would rate his performance as above average.
      The group demonstrated effective knowledge of UML.
      </long>
   </description>
</assertion>
<reflexion>
   <contentype>
      <referential>
      <indexid>reflexion_01</indexid>
      </referential>
   </contentype>
   <rationale>For my travel diary.</rationale>
   <date>
      <typename>
      <tysource sourcetype="standard">ePortfolio</tysource>
      <tyvalue>Create</tyvalue>
      </typename>
      <datetime>2004-02-13T18:12:45</datetime>
   </date>
   <description>
      <short>Thoughts on Zurich.</short>
      <long>Zurich is obviously a wealthy city.
      In some ways it would be good to live here, if one
      could afford it. But would I feel at home here?</long>
   </description>
</reflexion>

3.1.8 Competency

The <competency> element should be used as recommended in the LIP Best Practice Guide, sub-section 7.2.4 [LIP, 01].

Whenever possible, competencies should be defined using an instance of IMS Reusable Definition of Competency or Educational Objective specification [RDCEO, 02].

3.1.9 Goal

The <goal> element can be used to represent any kinds of goals of the subject, including those which have been completed, so that the goal can be compared with the actual achievement, which might be different, or be represented differently. Goals have a vital role in action planning, and comparing goals with what is actually achieved is an important source of feedback toward personal or professional development.

Careful distinction should be made between goals, which should represent future situations which are aimed for, and the actual achievement, qualification, product, competency, or whatever it is that is aimed for. In making this distinction, it can be helpful to note the specific criteria for success of the goal, and any time constraints.

3.1.9.1 <typename>

The type of the <goal> should reflect the context in which the <goal> is set and worked towards, e.g., "Work" and "Education". "Personal" <goal>s can be used to represent goals related to sports, hobbies, or interests.

A <goal> should be represented with the type "Development" when it is primarily aimed at personal, professional, or career development. This might overlap particularly with "Education" type goals, and consistent decisions should be made on which examples to represent as each type.

If there is a case in action planning for representing an obstacle (where there is an implied goal to overcome or circumvent the obstacle) this should be represented with a <goal> of type "Obstacle", and the obstacle itself should be described in place of the goal.

If it is necessary to represent a list of goals which cannot be distinguished into individual <goal>s, the type "List" should be used, and the description of the <goal> should hold the list. In this case, the short description of the <goal> should describe the collection of goals, and its long description should give the list itself.

3.1.9.2 <date>

If the information is available, the target date of completion should be represented with a <date> of type "Target", and if it has been completed, the actual <date> of completion should be represented with a <date> of type "Finish".

3.1.9.3 <priority>

As there is no provision for a typename for the <priority> element, the interoperable aspect of priority should be regarded as a representation of just the ordering of the set of goals within one ePortfolio. This should be done by representing the <priority> as a number, with a lower number representing a more important goal. The same number should be used to represent goals of equal priority.

Any numbers can be used which preserve the rank ordering, e.g., "1" to mean highest priority; "2" to mean high priority, "3" to mean medium priority, "4" to mean low priority, "5" to mean lowest priority. This means that priorities are only comparable between different ePortfolios by agreement of a more specific mapping.

3.1.9.4 <status>

The <status> of the goal should have a standard type, which can then be thought of as a property of the <goal>. An "Active" <goal> should be one that is actively being pursued or aimed at. A "Completed" <goal> should be one that has been completed to the satisfaction of whoever set the goal. An "Inactive" <goal> should be one that could be sought, but is not currently determining any choices of action, including one that is under consideration but has not been adopted. A <goal> which has missed the chance of being completed, or which has been abandoned, should be given the status type "Retired".

3.1.9.5 Nesting of Goals

Goals should not be represented as nested within other <goal> elements. This is because one lesser goal can support more than one greater goal, and even where only one is currently envisaged, it is impossible in the lifelong context to be sure that any goal will never support a further greater goal. Instead, the relationships between goals should be represented in <relationship> elements, as below.

3.1.9.6 Relationships Involving Goals

If any action planning is represented in the ePortfolio, the relationships between goals and between activities and goals should be represented. The case of other items contributing to goals should be represented as a relationship in which the other item "Supports" the <goal> element. Where one goal is a sub-goal of a greater goal, the relationship is that the lesser one "Supports" the greater.

Where a goal is conceived primarily as the achievement of a competency, qualification, or other kind of achievement, or as the completion of a product, the relationship should be that the <goal> "AimsAt" the other thing.

3.1.9.7 Examples

See the examples in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.4, in the light of the caution against nesting goals.

3.1.10 Identification

The <identification> element should be used as recommended in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.6.

Because a portfolio must have an owner, every portfolio must contain one <identification> element. The <identification> element identifies the owner of the portfolio.

3.1.11 Interest

Interests are important partly because they relate to motivation of the individual, and partly because they add depth and color to a personal portrait. They provide potential points of common interest and therefore discussion. It is not surprising, therefore, that interests are generally featured on CVs and résumés.

Interests as normally understood can include sports, hobbies, pastimes, and other recreational activities. The range of things that act as intrinsic motivators also includes personal values and beliefs, and there is no reason why these should not also be listed as interests.

3.1.11.1 <typename>

An <interest> should be represented with type "Participant" when the subject actually participates in activities directly related to the interest, e.g., embroidery, amateur dramatics, skiing.

An <interest> should be represented with type "Observer" when the subject watches activities related to the interest, and knows about the subject of interest, e.g., being a fan or supporter of a celebrity or team.

An <interest> should be represented with type "Value" when the interest is a general principle or belief system, e.g., world peace, vegetarianism, Hinduism, prison reform.

3.1.11.2 <product>

The <product> element should not be used as part of any <interest> element. If <product> elements were used here, there would be potential conflict with their use within <activity> elements.

3.1.11.3 Relationships Involving Interests

Where an <interest> is seen as a motivating factor for any other element, the <relationship> should be that the interest "Supports" the other element.

Where an <interest> forms part of another interest, the <relationship> should be that the more specific interest "IsPartOf" the wider interest.

Where an <interest> significantly came before another interest, the <relationship> should be that the earlier interest "Precedes" the later interest.

3.1.11.4 Examples

See the examples in LIP Best Practice Guide [LIP, 01] sub-section 7.2.7, but observe the caution against the use of <product> elements within <interest>s.

3.1.12 Participation

The Participation class defines a group of people, which may or may not include the Owner of the Portfolio. The <participation> element may be used to represent a group of people who collaborated on the creation of a Product, or participated together in an Activity.

This element can be represented using the XML binding of the Person, Group, and Membership data models defined in the data model of the IMS Enterprise Services v1.0 specification [ES, 04]. In a future version of the specification this may be revisited with a view to unifying the person structure with the identification structure.

3.1.13 Product

The Product data structure is used to contain the materials created by the learner. These materials may be created as part of formal activities and can take any electronic form e.g., text, MS Word document, Quicktime movie, HTML, etc.

This element is derived from the IMS LIP Specification [LIP, 01], but the storage of the actual "products" should be done via the Content Packaging specification [CP, 04] and in a similar way that one see the storage of content in a Course thus exported via the IMS Content Packaging specification.

3.1.14 Qualification

The <qualification> element should be used in accordance with the recommendations for the <qcl> element in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.8.

3.1.15 Rubric

Rubrics and the results of assessments using rubrics should be included using the Rubric Specification [RUBRIC, 05].

3.1.16 RubricCell

The RubricCell represents the intersection of dimensions of quality within a Rubric. A RubricCell may be used to refer to outcomes that occur at the intersection of dimensions of quality within a rubric.

3.1.17 Security Key

The <securitykey> element should be used as recommended in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.10.

3.1.18 Transcript

The <transcript> element should be used as recommended in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.11.

Whenever possible, transcripts should be defined using an instance of the an XML standard or specification appropriate for the sector in which the transcript data was produced. Transcripts specifications to be considered include the UK Higher Education Transcript and the Postsecondary Electronic Standards Council XML Postsecondary Transcript.

3.2 Other Implementation Information

3.2.1 Packaging

Guidance on packaging portfolios is given in the extended examples accompanying this specification. Normative rules for packaging can be found in the XML Binding [EP, 05b]. Multiple Views may be included by adding multiple View XSL files to the Portfolio Package. If a View is intended to include a presentation, a presentation XSL file for that view must be included in the Portfolio Package as well.

3.2.2 Grades

Grades given as part of a qualification or certificate should be represented within the <level> element of the <qcl> element. The <level> structure is nested or chained so that any level can have a further sub-level within it.

Grades or marks given for educational or other assessed activities are represented differently, within activity / evaluation / result. There is sufficient apparatus in LIP to represent results richly, and it is recommended to follow the LIP Best Practice Guide [LIP, 01] sub-section 7.2.8.

It may be that the results of an overall education activity are directly related to the level of the resulting qualification. Attention also needs to be given in future revisions of LIP for making it clear when there is such a relationship, and representing it unambiguously.

3.2.3 Multiple Owner ePortfolios

As noted previously, more than one owner can be associated with an ePortfolio. The expectation of the package is that all owners will be associated with the ePortfolio package. Depending on the model of the receiving system and whether all users and the group construct exists in the receiving system, the receiving system will associate the ePortfolio with one or more individuals and retain the group association, with individual users severing the group connection, or with the group of users as one entity.

3.2.4 Importance Meta-data

For certain types of ePortfolios, some components may be more important than others; some are so important that the ePortfolio has a substantially different meaning if they are omitted. For example, a portfolio whose visual presentation is designed, in itself, to attest to the author's skills as a graphic designer could not convey its intended meaning within a system that is incapable of reproducing that presentation. Information about the importance of various aspects of a portfolio may be described in a LOM record and included within the <organization> of the described portfolio within an ePortfolio package.

3.2.5 Advice on Referencing Portfolios and PortfiolioParts

PortfolioParts include the LIP contentype which supports two separate referencing mechanisms - 'sourcedid' and 'indexid'. Their use here is similar to their usage in the LIP:

  • 'Sourcedid' - the portfolio instance identifier. This consists of a source label, unique to the source responsible for creating or storing the portfolio instance, and the identifier of the record within that source. The source is responsible for ensuring that each different learner portfolio record has a unique identifier. For a portfolio instance this is used at a global level, i.e., not within a part;
  • 'Indexid' - each portfolioPart can use the indexid element of contentype to uniquely identify the part within the instance. This is necessary for references between parts in relationships.

For this version of the specification, the finest granularity of reference is the portfolioPart. That is, a relationship can exist only between portfolioParts.

Portfolios are referenced using two unique identifiers (it is important that these are not automatically generated/assigned without human confirmation):

  • Manifest Identifier - this should be a globally unique identifier;
  • Organization Identifier - this must be unique within the manifest and should be globally unique. It is this identifier that is used to uniquely identify the Portfolio.

Any alternative binding mechanism must also support an identifier extension equivalent to the LIP contetype structure.

3.2.6 Comments

Comments to be made that address the portfolioPart are stored in the LIP contentype structure.

4. Extended Examples

Accompanying the specification are some examples that have been packaged and described to demonstrate how implementations should package portfolios and how they should interpret packages. This section describes those examples. The conventions are also defined, without example, in the XML Binding [EP, 05b]. The Rubric Specification [RUBRIC, 05] also includes examples. The code for these examples is provided on the IMS website http://www.imsglobal.org/ep/.

4.1 Minimal Example

This shows an absolute minimal portfolio for exporting just one product, an assignment essay. The portfolio package directory is named 'minimalPortfolio'. The component files are:

  • The manifest file - 'imsmanifest.xml';
  • The identification instance file - 'minimalIdentification.xml';
  • The product instance file - 'minimalProduct.xml';
  • The work product is a single Microsoft Word file - 'Midterm_research_Project_hollandp_Arthur.doc'.

There are no views or style files. A schematic visualization of the subsequent portfolio package is shown in Figure 4.1.

Figure 4.1 Graphical representation of minimal portfolio example.

4.2 Reflexion and Assertion Example

This example has the same structure as the minimal example, as well as a product instance that contains a reflexion, an assertion, and an accessibility preferences instance for the portfolio. The portfolio package directory is named 'ReflectNassertPortfolio'. The component files are:

  • The manifest file - 'imsmanifest.xml';
  • The identification instance file - 'Identification.xml';
  • The product instance file - 'Product.xml';
  • The work product is a single Microsoft Word file - 'Midterm_research_Project_hollandp_Arthur.doc';
  • The reflexion instance file - 'Refexion.xml';
  • The assertion instance file - 'Assertion.xml';
  • The accessibility preferences instance file - 'Accessibility.xml';
  • The relationship instance file - 'Relationship.xml'.

There are no views or style files. A schematic visualization of the subsequent portfolio package is shown in Figure 4.2.

Figure 4.2 Graphical representation of reflexion and assertion portfolio example.

4.3 Views and Style Example

This is a more extensive example showing the structure of files for packaging where views and presentations are involved. The package contains three portfolios for: "Joanna Hunt", Gayle Beneville" and "Company Competencies". The first two are associated with individuals and the third with a group of individuals and shows the competencies the group has between them but not associated with each individual. These three portfolios are bundled using a fourth package, as shown in Figure 4.3.

Figure 4.3 The package of portfolio packages example.
The individuall portolio packages for JoAnna Hunt, Gayle Beneville, and Programming Competencies are shown in Figures 4.4, 4.5, and 4.6 respectively.
The Hunt package consists of several product PortfolioParts and a views section that provides a rubric view. The portfolio package directory is named 'HuntPortfolio'. The component files are:
  • The manifest file - 'imsmanifest.xml';
  • The identification instance file - 'Identification.xml';
  • The product instance files - 'ProductPhoto.xml', 'ProductMysenblack.xml', 'ProductResume.xml' and 'ProductSample.xml'. The associated artifact files are given in the directory 'content';
  • The view files are given in the directory 'views'.

Figure 4.4 JoAnna portfolio example.

The Beneville package consists of several product PortfolioParts. The portfolio package directory is named 'HuntPortfolio'. The component files are:

  • The manifest file - 'imsmanifest.xml';
  • The identification instance file - 'Identification.xml';
  • The product instance files - 'ProductMidTermProj.xml', 'ProductAbsolutism.xml', 'ProductRevolution.xml' and 'ProductOceanEssay.xml'. The associated artifact files are given in the directory 'content'.

Figure 4.5 Beneville portfolio example.

The Competencies package consists of single competency. The portfolio package directory is named 'CompetenciesPortfolio'. The component files are:

  • The manifest file - 'imsmanifest.xml';
  • The identification instance file - 'Identification.xml';
  • The competency instance file - 'programmingCompetencies.xml'.

Figure 4.6 Competencies portfolio example.

5. Implementation

There are a wide range of systems that could be called ePortfolio systems or carry some ePortfolio functionality. It is likely for existing systems that implementation will require identifying mappings of elements defined in this specification against existing system data elements and functionality. The following example of this mapping partially constructed for an existing system was supplied by Ufi learndirect (http://www.ufi.com/).

The following example is provided to demonstrate the kind of thinking and approach required to implement portfolio export/import capability from/to an existing system.

5.1 Mapping of learndirect ePortfolio Data to IMS ePortfolio Specification

This example maps the learndirect eportfolio elements to the IMS ePortfolio specification.1 The purpose is to help validate the applicability of the IMS ePortfolio specification to a major real-life e-learning environment.

Table 5.1 Possible mapping of learndirect data entities to IMS ePortfolio Classes.

learndirect data entity IMS EP Class Comments and relationships
Personal notebook entry Reflexion Same mapping of attributes as "organiser entry" (below).
Organiser "folder" entry.
("Where am I now?",
"How will I get there?", etc.)
Reflexion The entries in organiser are held in "folders" which the system provides- e.g. "Where am I now?", "Where do I want to go" "How will I get there?", "personal notebook". These would be represented by the Rationale attribute.
The heading and body of the entry would be represented by the Description attribute - under <short> and <long> respectively.
Course notes entry Reflexion Same mapping of attributes as "organiser entry" (above).
Linked via a relationship object to an Activity object representing the course enrolment.
Course enrolments
Course completions
Activity In the learndirect LSE, these can be viewed in "my learning summary".
Learner's "own learning activities" Activity In the learndirect LSE, these can be viewed in "my learning summary": they are entered directly by the learner.
Evidence entries
(In "manage my evidence" and "evidence for qualifications" folders.
Reflexion Same mapping of attributes as "organiser entry" (above).
Linked via a relationship object to a QCL (Qualification) object representing the award registration.
Optionally linked via a relationship object to an Activity object representing the course - if this entry originated as a course note.
Award registrations and achievements QCL (Qualification) The QCL object would contain summary details of the award - name, level, awarding body, etc., as well as information, like the date awarded, about the specific learner's achievement.
Unit registrations and achievements QCL (Qualification) Units are parts of awards.
Linked via a relationship object to a QCL object representing the parent award registration.
Notes on award or unit achievements / registrations Reflexion Linked via a relationship object to a QCL object representing the award / unit achievement.
Notes can be either on registration, or on achievement. The Authorship of the note will be the name of the learning centre staff member who entered it.
Elements of "my learning plan"* Reflexion "My learning plan" contains a number of elements - rendered on one page - e.g. "What do I want to learn?", "what do I know already?".
Each element would be represented by one reflexion record.
Progress records* Reflexion Linked via a relationship object to an Activity object representing the course enrolment.
Authorship of the note will be the name of the tutor who entered it - or the learner, as appropriate.
Learning outcomes Competency Linked via a relationship object to an Activity object representing the course enrolment.
Status can be achieved, or targeted.
Personal Learning goals for course Goal Linked via a relationship object to an Activity object representing the course enrolment.
Status can be achieved, or targeted.
Comments / feedback on achievement of learning outcomes and goals Reflexion Linked via a relationship object to the competency / goal object representing the learning outcome / goal
Authorship of the comment will be the name of the tutor who entered it
Learner details Identification Learner's name.
Could include data like the learner's address, postcode, unique user id, etc. - this depends on learndirect's privacy policy, as to whether or in which circumstances it is included in exports.
Attachments Product Multiple files may be attached to LSE entries - evidence, organiser entries, notebook entries, etc. These could be word documents, spreadsheets, images, sound recordings, videos, etc...
These will be held in the content package which wraps the eportfolio entries (see below) and referenced via an exrefrecord object.

5.1.1 Binding and Packaging

Records would be bound in XML, following the IMS Eportfolio XML Binding Guide.

They would typically be exported and transferred in an IMS content package, as described in section 3*** of the IMS Eportfolio XML Binding Guide. A package would typically contain one or more portfolio XML instances, along with a number of "products" which are attachment files. (See also "attachments" above.)

Notes:

  1. There are a number of levels of detail which might be relevant in different scenarios. For example, in some cases, the learner's own reflective entries, and achievements in terms of course completions and awards may be required, but not the fine detail of learning outcomes, comments on achievement of learning outcomes, which make up a course. In other cases, everything may be desirable.
  2. Where reflective records, analogous to learndirect organiser entries, are imported from another eportfolio system, they are very unlikely to be organised into the same folder structure ("Where am I now?", "Where do I want to go?" etc.) as the learndirect organiser. The expectation would be that these records would be imported as a linear set of entries, with the "type" of entry recorded against it.
  3. Most of the learndirect data entities identified below are currently in the live system. Others are planned for the next release (8.3). The latter are identified by a * in the table above.
  4. For the purposes of this document, the within-course assessments completed by a learner as part of their learning on a course are regarded as local to that course, and not to be carried with the learner when they transfer their eportfolio to another institution. (Unless they form evidence for awards, in which case they are transferable.) However, it would be perfectly possible to incorporate within-course assessments, and tutor feedback on them, if this was wanted.

6. Conformance

Conformance to the ePortfolio Specification addresses the ability to export and import an ePortfolio into the conforming ePortfolio system. A system must declare the nature of its conformance, i.e., does it import only, export only, or support import and export.

6.1 Import Definition

The system that claims conformance as an ePortfolio import capability must:

  1. Read and 'understand' an IMS Content Package manifest file as profiled for an ePortfolio;
  2. Must reject as invalid a Portfolio Package that does not have a PortfolioPart with a title 'Identification', i.e., is must have the structure:
   <organization identifier = "[..]"
      ...
      <item identifier = "[...]">
         <title>PortfolioParts</title>
         <item identifier = "[...]" identifierref = "[...]">
            <title>Identification</title>
         </item>
      </item>
      ...
   </organization>
  1. Must store and make available to the user in some fashion all of the data it receives within an imported Portfolio Package, even if it is unable to decode the semantics of this information (i.e., the system should not discard data it does not understand).

6.2 Export Definition

The system that claims conformance as an ePortfolio export capability must meet the following:

  1. The Portfolio Package must be a well-formed IMS Content Package as profiled for an ePortfolio. This includes that the Portfolio Package manifest must have the structure:
   <manifest xmlns = "http://www.imsglobal.org/xsd/imsportfoliocp_v1p0" 
         xmlns:xsi = http://www.w3.org/2001/XMLSchema-instance
         xsi:schemaLocation = "http://www.imsglobal.org/xsd/imsportfoliocp_v1p0
         http://www.imsglobal.org/xsd/imsportfoliocp_v1p0/imsportfoliocp_v1p0.xsd"
         identifier = "[...]" 
      version = "1.0">
         <organizations default = "[...]">
            <organization identifier = "[...]">
               ...
            </organization>
      </organizations>
         <resources>
         ...
         </resources>
   </manifest>
  1. The Portfolio must have one 'Identification' PortfolioPart. This means that the Portfolio Package manifest must have the structure:
   <organization identifier = "[..]"
      ...
      <item identifier = "[...]">
         <title>PortfolioParts</title>
         <item identifier = "[...]" identifierref = "[...]">
            <title>Identification</title>
         </item>
      </item>
      ...
   </organization>

About This Document

Title IMS ePortfolio Best Practice and Implementation Guide
Editors Darren Cambridge (EDUCAUSE), Colin Smythe (IMS), Andy Heath (EPICC)
Team Co-Leads Darren Cambridge (EDUCAUSE), Andy Heath (EPICC)
Version 1.0
Version Date 02 June 2005
Status Final Specification
Summary This document describes the Best Practice and Implementation Guide of the ePortfolio specification.
Revision Information 02 June 2005
Purpose This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location http://www.imsglobal.org/ep/epv1p0/imsep_bestv1p0.html

To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=24

List of Contributors

The following individuals contributed to the development of this document:

Name Organization
Darren Cambridge EDUCAUSE
Christopher Etesse Blackboard
Jessica Finnefrock Blackboard
Simon Grant CETIS
Andy Heath EPICC
Glenn Johnson Penn State University
Cindy Mazow Thomson Learning
Mark McKell IMS Global Learning Consortium, Inc.
Colin Smythe IMS Global Learning Consortium, Inc.
Scott Wilson CETIS

Revision History

Version No. Release Date Comments
Base Document 1.0 29 March 2004 Initial version of the ePortfolio specification.
Public Draft 1.0 20 September 2004 Public Draft version of the ePortfolio Best Practice and Implementation Guide.
Final 1.0 02 June 2005 Final version of the ePortfolio Best Practice and Implementation Guide.

Index

A
Accessibility 1, 2

B
Behavior 1
Binding 1, 2, 3, 4

C
CSS 1

E
Elements
relationship 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
ePortfolio 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
 

I
IMS Specifications
AccessForAll Meta-data 1
Content Packaging 1
ePortfolio 1
Learner Information Package 1, 2, 3, 4, 5, 6, 7, 8, 9
Learner Information Package Accessibility for LIP 1, 2
Reusable Definition of Competency or Education Objective 1
Interoperability 1
 

L
Learning 1, 2, 3, 4, 5, 6
Learning Object 1, 2
LOM 1

M
Meta-data 1, 2

N
Namespace 1
Normative 1, 2, 3

P
Package 1, 2, 3, 4
Portfolio 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Preferences 1, 2, 3

R
Records 1, 2
Rubric 1, 2

S
Schema 1
Services 1
Standards 1, 2, 3, 4, 5
Structure 1, 2, 3, 4, 5, 6

V
Vocabulary 1, 2

W
W3C 1, 2, 3

X
XML 1, 2, 3, 4, 5, 6
XSD 1
XSL 1
XSLT 1, 2
 

1 As specified in the IMS ePortfolio Version 1.0 specifications. (Best Practice Guide, Information model, and XML Binding documents.) See http://www.imsglobal.org/ep/

 

 

 

IMS Global Learning Consortium, Inc. ("IMS/GLC") is publishing the information contained in this IMS ePortfolio Best Practice and Implementation Guide ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

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

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

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

IMS/GLC would appreciate receiving your comments and suggestions.

Please contact IMS/GLC through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS ePortfolio Best Practice and Implementation Guide Revision: 02 June 2005