Stakeholder Concerns
This page provides a summary of the concerns documented in the report. Please feel free to add additional concerns here or comment on existing ones.
Ownership
The question of ownership emerged as the key differentiator between ePortfolios and other school-based learning technology tools. In an ePortfolio, the student owns the space, they decide what goes into it, how it is structured and who to share it with. By contrast the LMS and ePortfolio-like activities within the context of the LMS or other school systems are 'owned' and managed by the school. Therefore there is (for example) a profound contextual difference between a reflective blogging task within the LMS and the same task within your own ePortfolio environment with respect to ownership (and responsibility for) both the artefact and the process.
This concern was highlighted by almost all stakeholders interviewed and if it is treated as a top-level consideration, then it holds significant implications for the way in which other concerns may be handled from an architecture perspective: both simplifying and constraining many of the functional requirements of interoperability. These are outlined throughout the rest of the document. The fact that MyPortfolio is being provided as a national hosted service outside of any particular insitution's field of responsibility serves to support the conceptual distinction being made here of student-owned and school-owned systems.
However it is important to note that in practical terms (especially where younger children are concerned) 'student-owned' does not mean there is no teacher involvement in directing ePortfolio activies or managing ePortfolio content. There is a continuum of 'student-ownership' which has to do with both the maturity of the students and the purpose of the ePortfolio in a particular educational context.
Assessment This concern relates to how assessed content should be treated in the ePortfolio environment. The first point to consider here is that Mahara / MyPortfolio is not really designed to be an environment which handles formally assessed content, it is more intended to be an environment in which the student collects artefacts which are evidence of a personal learning journey for reflection upon by themselves and given over to view for feedback by others. This perspective is in keeping with the ownership distinction mentioned above. Insitution-managed systems are designed to handle and verify assessment information. The LMS typically provides many tools for this purpose and the SMS is the authoritative source of Grade information. These systems are controlled by the institution. The ePortfolio is owned and managed by the student, so should not be considered an authoritative source for assessment information. What if the student were to edit the work after it had been assessed in the ePortfolio? What if they were to change the grade? Or if they were to selectively edit out less positive comments after the fact? If we accept the ownership distinction made earlier, then we might respond – “Well, so what if they do?” It is nothing that they couldn't do in other ways if they so desired and if it is not relied upon as an authoritative source on assessment then it shouldn't matter.
However it is likely that students will want to export some completed and assessed work from the LMS into their ePortfolio as evidence for presentation to third parties. One option to achieve this would be to transfer a 'locked' artefact from the LMS which can be appended and annotated with reflections and commentary but cannot actually be changed. An argument against this approach is that if the Portfolio is owned by the student, then it shouldn't really contain 'locked' artefacts that the can't edit, also it is part of the learning process to continue to improve a piece of work. Another approach that has been suggested would be to use digital signatures such as xml-signatures to ensure that a third-party can verify that signed content hasn't be subsequently amended.
Another reason to want to transfer a locked “snapshot” of artefacts at a particular point in time would be if the portfolio itself (or a view rather) were to presented for assessment. Rather than attempting to 'lock' assessable views in MyPortfolio which would again contravene the principle that the ePortfolio is student -owned and managed, one way to handle it would be to export a time-stamped, digitally signed snapshot of the view into the teacher's space in the LMS for assessment. The responsibility for maintaining verified copies of assessed work then passes (appropriately) to the institution and mechanisms to support this are out of scope of the current work.
It has been mentioned that the use of embedded video/audio stored on third party servers (e.g YouTube) presents issues for maintaining a verified and complete copy of a students view since the links may disappear. While it is worth noting this again is a pattern of use issue which is beyond the scope of the current work.
Updating and Versioning
This concern bears some relation to the previous one but in a more general sense. Should exported content be versioned to provide a history or overwritten when an updated version is exported? The view was expressed that versioning is desirable because the existence of several versions of the same work as it progresses provides rich evidence of the learning journey. Ideally both options would be available.
Exporting and Displaying Structured Content / Activities
Some content types are simple unitary enitities such as a blog post or a single file. Other pieces of content may be structured into several hyper-linked html pages, perhaps with embedded images or other linked files which also need to be transported, and with comments or other annotations. In such cases the content needs to be exported in such a way as to take all necessary additional files with it and re-link them appropriately as well as making sure all other links remain valid. In addition the remote system needs to know (or make some sensible decisions about) how to display the content in a way that makes sense.
The export format used should be able to handle structured content. LEAP2A is able to do this through the use of relationship elements.
Contributions of Others and Licensing
If an LMS activity involves the collaborative input of several students, or in the case of a discussion thread, the views of several participants are expressed, then should a student be permitted to export that activity in its entirety to their ePortfolio? Should they be able to do it at all? Should they only be able to do it with the permission (either implicit or explicit) of the other participants? Currently when Moodle discussion forums are exported to Mahara, all posts other than those by the exporting user are removed. This is one way to handle the issue but all of the context of the discussion is lost. One suggestion was to apply a creative commons licensing scheme attached to certain LMS collaborative activities such as discussions that provides consent for the materials to be exported to ePortfolio environments by any of the participants.
Privacy and Access
If the ePortfolio is student owned and managed, then should student have the ultimate right to grant or deny access to staff members (teachers and school IT staff) to their account information. Naturally this doesn't make sense for younger children whose ePortfolio activities are to a large extent directed and managed by the teacher and / or parents. At what point would control in managing access be handed over to the students themselves? This is a valid concern but is a pattern of use question that is out of scope of this work. No technical solution is being considered.
Notifications
In situations where parents are encouraged to use the Parent Portal as the primary point of access to their childs' work and education information, then MyPortfolio should provide a notification to the Parent Portal when a view pertaining to the parent has been created or updated. Similarly teachers expressed the need for MyPortfolio to provide Notifications through to their space in the LMS when ePortfolio views have changed in some way. Currently Mahara provides email notifications which don't contain any information about what has changed. At a minimum it need to supply the student's name, the item / view that has changed and a URI link back to the view.
The view was expressed that the notifications mechanism could easily be set-up using an Atom feed from MyPortfolio which is consumed by a lightweight feed-reader built into the LMS / Parent Portal systems. The notification payload should be as lightweight as possible to avoid performance/scalability issues (with a single national service there could be a very high quantity of notification traffic) and secondly to reduce the need for security mechanisms to an insignificant level. This means that no actual content should be exchanged as part of the notification mechanism.
One problem with the notification scheme for parents is that unless parents have a log-in to MyPortfolio which they rarely do (for reasons of server loads and the undesirability of having to provide a service which caters for all parents nationally as well as students), they can't currently receive notifications. Normal parent access to a view is through the 'secet-url' mechanism. It was noted that the secret-url model is very weak from a security perpective. Yet allowing for parent accounts is undesirable from a management perspective. If parent access is only permitted through a school parent portal system, then an alternative scheme using delegated server-to-server authentication and authorisation (e.g.OAuth) could allow parents to receive notifications and access views in a secure environment using the parent portal as an intermediary.
An additional comment on notifications was that a one-way flow from MyPortfolio out may not be sufficient, and that perhaps MyPortfolio should accept notifications that feedback on a view has been placed, so that the student can in turn react to the update. This may be useful but is not being considered in the first phase of this work.
Notifications can use an Atom feed-based approach and should be very lightweight Clicking on the URI creates a LEAP2A GET request which exports the view contents to the Parent Portal Notifications should include name, view, and a URI to the view
Parents should access views through the parent portal rather than directly through secret-url if possible. Parent Logins to MyPortfolio are undesirable from a Management perspective
Relationship with internal LMS E-Portfolio Tools
LMS systems typically provide their own ePortfolio-type tools or activities to one extent or another (e.g. KnowledgeNet, Moodle and Ultranet all do). How would MyPortfolio work with those tools? Once again the question of ownership provides a useful top-level distinction here. Where ePortfolio tools and activities are provided within the LMS, they are still part of the school-owned and managed set of tools. MyPortfolio sits outside of that. Which activities take place in the LMS ePortfolio tools and which in MyPortfolio (if both are available) is a pattern of use question that is up to the direction of the individual teacher or institution policy.
Supporting Lifelong (Lifewide) Learning
The provision of MyPortfolio as a hosted national service provides an extremely practical foundation for the broader role of ePortfolios in supporting lifelong learning as students move between educational institutions. However this raises the question of identifying students as they move between institutions and how many accounts each student can have in MyPortfolio. Whilst this broader question is out of scope of the project, it does bear on the issue of implementing user provisioning and student account creation in each institution. If students were to be provided automatically with a new account in each new institution they move, then it would be important for them to be able to export their portfolio materials from a previous account into their new one (which can be done in Mahara using the existing LEAP2A import and export functionality) or simply to opt to keep using their old account perhaps, though this might have some ramifications for provisioning.
Students might need a GUID within MyPortfolio which extends beyond institution boundaries. The NSN is a candidate if MOE business rules permit this.
Interoperability Specifications and LEAP2A
One of the key concerns expressed by many stakeholders was related to the use of some kind of standard for the XML encoding and transport of portfolio information. The dominant ePortfolio specification (also commonly regarded as the simplest to implement) is LEAP2A. The LEAP2A specification has been implemented in Mahara since version 1.2 for import and export of either a full portfolio or a single view. This is primarily for extracting ePortfolio information for import into another ePortfolio system and vice versa. It is not a mechanism for automated transfer or for more granular information such as a single blog post. Nevertheless the Mahara team have considerable experience with LEAP2A implementation. Many stakeholders expressed the notion that export should use a standard format with LEAP2A as the principal candidate.
