IMS ePortfolio Best Practice and Implementation Guide

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
Date Issued:
02 June 2005
Latest version:
http://www.imsglobal.org/ep/epv1p0/imsep_bestv1p0.html
Register comments or implementations:
http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=24
IMS welcomes feedback on informing best practices for formulating portfolio packages:http://www.imsglobal.org/problemtracking/index.cfm
IMS Global Learning Consortium has made no inquiry into whether or not the implementation of third party material included in this specification would infringe upon the intellectual property rights of any party.
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.
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/.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT 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 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 element. This element allows for a portfolio to be identified with an individual, several individuals, or an organization by using the and 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 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
Every element should have a type, chosen from a controlled vocabulary, represented in the 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 , , or 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 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 or 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 , , or 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 , , or element, as source, is considered as indirect evidence of an interest, as destination; and fourthly, where a or 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 , as source, is related to any other element, as destination, and where no other relationship expresses any more specific relationship. The can either simply be the product of the subjects reflective activity, or it can be explanatory in any other general way. Such a might be created by anyone, in which case it would be the , 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 element, instead of the "Supports" relationship, to relate a single element, as source, to the element, as destination, where the element represents the overall educational program which leads to the award of the qualification represented in the 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
There should be exactly one element in any .
The and elements of the tuple should hold the indexid elements given in the referential element of the 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 element of the tuple is required by the IMS LIP 1.0 specification, but the specified use is already satisfied by the 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 element of the , 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
The element should be used to give supplementary information about a relationship. It should neither be used to substitute for the 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 element. If the description is longer than 255 characters, a summary of less than 255 characters should be given in the element, and the description in the element.
Examples:
ePortfolioSupplementsrelationship_01ePortfolio_Example1001activity_01results_inePortfolio_Example1001qcl_01The detailed transcript for an awarded qualification3.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 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 (seesub-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 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 and 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 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 or element should be used instead.
The main category of 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 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 elements created in this way can then be related to the objects of reflection through elements.
An 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 elements include: claiming competency; attesting another element; presenting any other element; recording an agreement.
3.1.7.1
The following is is not an exclusive list of typenames; types should be drawn from whatever controlled vocabulary is being used.
An element should be represented with type "Agreement" if its main purpose is to hold an agreement.
An 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 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 or element should be represented with type "ContextDefined" if its context and function is represented adequately by the relationships in which it participates.
A or element should be represented with type "Strengths" if its main purpose is to express one or more competencies possessed by the subject.
A or element should be represented with type "Valuation" if its main purpose is to evaluate some other element of the ePortfolio.
A or 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 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 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 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
The element should express the authorship of the or , 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 element is not present, the author is assumed to be the subject of the ePortfolio.
3.1.7.3
A or can have any number of elements. The rationale should represent the intended audience of the or 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
A of type "Create" should be used to represent the date on which the or was first composed.
A of type "Update" should be used to represent the date on which the or 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 of type "Reference" should be used to represent any date which forms the context of the or , i.e. a date on which any events reflected on or attested actually took place.
A of type "Publish" should be used to represent a date on which the or was published or made generally available to the public.
3.1.7.5
A of type "Draft" should be used to qualify a or which is being worked on, where the author is not yet satisfied that it represents what is intended.
A of type "Completed" should be used to qualify a or which has been finished, where the author is satisfied that it represents what is intended.
A of type "Expired" should be used to qualify a 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 and elements. In the following cases, the or element is the source of the relationship, and the other element the destination.
A of type "Attests" should accompany an element which is intended to certify of any other element of the ePortfolio.
A of type "Evaluates" should accompany a or 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 of type "Presents" should accompany an element whose purpose is to express any element of the ePortfolio in words suitable for a particular audience and purpose.
A of type "ReflectsOn" should accompany any element which relates to any element of the ePortfolio in a way not covered by other relationships.
Where there is a of type "Evidences" between any elements of the ePortfolio and a competency, and an element explains the way in which the other element serves as evidence of the competency, that element should be the source of a relationship of type "Claims", with the evidential relationship as destination.
3.1.7.7 Examples
assertion_01Dr. A. Brown (tutor)A witness statement relating to group assignmentePortfolioCreate2004-05-31T12:25:43Michael Short‘s group workI supervised the group assignment on UML modelling.Michael related well to the rest of his group, displaying significantleadership potential. He initiated task-oriented communicationsand played an active role in conflict resolution.Overall, I would rate his performance as above average.The group demonstrated effective knowledge of UML.reflexion_01For my travel diary.ePortfolioCreate2004-02-13T18:12:45Thoughts on Zurich.Zurich is obviously a wealthy city.In some ways it would be good to live here, if onecould afford it. But would I feel at home here?3.1.8 Competency
The 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 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
The type of the should reflect the context in which the is set and worked towards, e.g., "Work" and "Education". "Personal" s can be used to represent goals related to sports, hobbies, or interests.
A 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 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 s, the type "List" should be used, and the description of the should hold the list. In this case, the short description of the should describe the collection of goals, and its long description should give the list itself.
3.1.9.2
If the information is available, the target date of completion should be represented with a of type "Target", and if it has been completed, the actual of completion should be represented with a of type "Finish".
3.1.9.3
As there is no provision for a typename for the 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 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
The of the goal should have a standard type, which can then be thought of as a property of the . An "Active" should be one that is actively being pursued or aimed at. A "Completed" should be one that has been completed to the satisfaction of whoever set the goal. An "Inactive" 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 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 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 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 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 "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 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 element. The 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
An 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 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 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
The element should not be used as part of any element. If elements were used here, there would be potential conflict with their use within elements.
3.1.11.3 Relationships Involving Interests
Where an is seen as a motivating factor for any other element, the should be that the interest "Supports" the other element.
Where an forms part of another interest, the should be that the more specific interest "IsPartOf" the wider interest.
Where an significantly came before another interest, the 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 elements within 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 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 element should be used in accordance with the recommendations for the 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 element should be used as recommended in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.10.
3.1.18 Transcript
The 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 element of the element. The 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 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 websitehttp://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 and 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:
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. 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. 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. 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:
Read and ‘understand‘ an IMS Content Package manifest file as profiled for an ePortfolio; Must reject as invalid a Portfolio Package that does not have a PortfolioPart with a title ‘Identification‘, i.e., is must have the structure:
... 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:
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:
...... The Portfolio must have one ‘Identification‘ PortfolioPart. This means that the Portfolio Package manifest must have the structure:
...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
Accessibility1,2
B
Behavior1
Binding1,2,3,4
C
CSS1
E
Elements
relationship1,2,3,4,5,6,7,8,9,10,11
ePortfolio1,2,3,4,5,6,7,8,9,10,11,12,13,14
I
IMS Specifications
AccessForAll Meta-data1
Content Packaging1
ePortfolio1
Learner Information Package1,2,3,4,5,6,7,8,9
Learner Information Package Accessibility for LIP1,2
Reusable Definition of Competency or Education Objective1
Interoperability1
L
Learning1,2,3,4,5,6
Learning Object1,2
LOM1
M
Meta-data1,2
N
Namespace1
Normative1,2,3
P
Package1,2,3,4
Portfolio1,2,3,4,5,6,7,8,9,10,11
Preferences1,2,3
R
Records1,2
Rubric1,2
S
Schema1
Services1
Standards1,2,3,4,5
Structure1,2,3,4,5,6
V
Vocabulary1,2
W
W3C1,2,3
X
XML1,2,3,4,5,6
XSD1
XSL1
XSLT1,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 athttp://www.imsglobal.org
Please refer to Document Name: IMS ePortfolio Best Practice and Implementation Guide Revision: 02 June 2005
_xyz