IMS ePortfolio Best Practice and Implementation Guide
Version 1.0 Final Specification
|
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/.
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].
The structure of this document is:
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.
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.
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:
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.
ePortfolio services and behaviors are explicitly out of scope for this specification document.
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.
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.
The ePortfolio specification is comprised of the following documents, each with distinct scope:
Describes the core aspects of the specification and is normative for any binding claiming to use this information model. It contains details of: semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whether mandatory or optional). 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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
Trigger:
At critical junctures within a course of study defined
by instructor, the instructor reviews the learning ePortfolio of
a student in the course.
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
Preconditions:
The author has assembled an ePortfolio of any type.
Trigger:
The primary author creates an export package of the
ePortfolio.
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.
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.
Multiple views may be defined within a portfolio through the use of multiple presentations.
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.
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.
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.
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.
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.
<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>
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.
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:
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].
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.
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.
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.
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.
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.
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.
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.
<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>
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].
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.
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.
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".
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Rubrics and the results of assessments using rubrics should be included using the Rubric Specification [RUBRIC, 05].
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.
The <securitykey> element should be used as recommended in the LIP Best Practice Guide [LIP, 01] sub-section 7.2.10.
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.
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.
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.
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.
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.
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:
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):
Any alternative binding mechanism must also support an identifier extension equivalent to the LIP contetype structure.
Comments to be made that address the portfolioPart are stored in the LIP contentype structure.
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/.
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:
There are no views or style files. A schematic visualization of the subsequent portfolio package is shown in Figure 4.1.
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:
There are no views or style files. A schematic visualization of the subsequent portfolio package is shown in Figure 4.2.
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.
The Beneville package consists of several product PortfolioParts. The portfolio package directory is named 'HuntPortfolio'. The component files are:
The Competencies package consists of single competency. The portfolio package directory is named 'CompetenciesPortfolio'. The component files are:
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.
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.
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.)
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.
The system that claims conformance as an ePortfolio import capability must:
<organization identifier = "[..]"
...
<item identifier = "[...]">
<title>PortfolioParts</title>
<item identifier = "[...]" identifierref = "[...]">
<title>Identification</title>
</item>
</item>
...
</organization>
The system that claims conformance as an ePortfolio export capability must meet the following:
<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>
<organization identifier = "[..]"
...
<item identifier = "[...]">
<title>PortfolioParts</title>
<item identifier = "[...]" identifierref = "[...]">
<title>Identification</title>
</item>
</item>
...
</organization>
| 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 |
The following individuals contributed to the development of this document:
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
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
S
Schema 1
Services 1
Standards 1, 2, 3, 4, 5
Structure 1, 2, 3, 4, 5, 6
X
XML 1, 2, 3, 4, 5, 6
XSD 1
XSL 1
XSLT 1, 2
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