Introduction
Leap2A represents portfolio information as an Atom feed, with optional attachments. An Atom feed consists of entries. One blog post corresponds to one entry. Whether information is represented in entries or in attachments depends on the kind of information.
Different kinds of portfolio information
There are three different kinds of information that are often included in portfolios:
- digital artefacts made or jointly made by the portfolio holder
- information about the portfolio holder, their abilities, achievements, experiences, activities, goals, plans and such like;
- things written that are not specifically about one of the things above — these may include blog posts, comments, reflections, etc.
In a portfolio, any selection of these can appear together, as a set of single, self-contained portfolio items. The items themselves are the minimal units of information that make sense in their own right, and could be reusable separately from other portfolio items. Information managed by an e-portfolio system is just that which the portfolio holder wants to keep or maintain, perhaps to reflect on, and potentially to present to others. Information collected by other people for their purposes could be represented in the same format, though one would not call it portfolio information.
Digital artefacts, including audio, video, multimedia as well as plain word processed files, may have some associated information, including metadata such as author or owner, date of creation, modification, etc., title, perhaps summary. They exist as self-contained entities, and a portfolio holder very commonly presents them by way of evidence for their abilities. The item here is the combination of the artefact itself and any metadata represented within the portfolio system. How this is done in Leap2A is described in the Leap2A/files page.
Short expressions may have their own self-contained meaning, as for example in diary or blog entries. Alternatively they may be tied to something else. For example, a PDP process may include a learner reflecting on the strengths, weaknesses, opportunities and threats connected with one aspect of their situation. The user interface could present these as separate text boxes, so that they can be held and managed separately. Each one could have its own creation and modification dates. In this case, though the piece of text is only fully understood in its context, it nevertheless exists in its own right, as it has its own creation and modification dates, and could even have a different author. Each expression is a separate portfolio item.
Information about particular things is again of two kinds. Firstly, it can be information directly related to the thing. An obvious example is the dates associated with things that have happened, or are planned to happen. These dates have no meaning at all separated from the portfolio item they refer to. Secondly, much other information about particular things is given by the relationships between that thing and other items. A portfolio item in this case is just the information directly related to the thing, that has no separate meaning on its own. For portability of information and interoperability of systems, it is vital to be able to identify, in a common way, the type of thing which a portfolio item holds information about. Nearly all e-PDP and e-portfolio systems make distinctions of this nature.
Given the approach of regarding portfolio items as very small sets of tightly related information, representing the relationships between portfolio items is also centrally important to capturing the meaning of portfolio information. The user interface of a portfolio related tool may invite the learner to enter text under many different rubrics, and the significance of the text entered will depend on the context in which the learner was invited to enter the text.
Selections of portfolio items are also an important aspect of portfolio practice. Portfolio information is generally thought of as collected, selected and presented, and many portfolio systems allow other people to see such selections.
The structure of an Atom feed
Within an atom:feed, the principal component structure in Atom is the atom:entry element. The main correspondence is therefore between Atom entries and portfolio items, as described above: each item corresponds to just one entry. Blog information is essentially of one kind only: authors write blog entries, which can be about anything. Thus there is no provision within Atom to distinguish types of entry, and therefore "foreign" elements in the entries are used to represent portfolio item types. Atom does, however provide the atom:category element, which is used in this specification to represent some finer distinctions of category.
The granularity of the information is highly significant. As each portfolio item is a relatively small set of information that only makes sense together, there will be a relatively large number of relationships between the portfolio items (or Atom entries). Atom provides the atom:link element to represent entry relationships, but the Atom vocabulary for links is much smaller than what is needed to represent the kinds of relationship between portfolio items. So this specification extends Atom by providing extra values for the "rel" attribute of link, corresponding to the relationship types that have been agreed practically useful in existing portfolio systems.
Atom does not have any structure particularly adapted for selections. An entry is used, with links to the items included in the selection.
Small pieces of information, such as contact details, do not map well onto Atom, and they are therefore represented differently in Leap2A. All such details about the author, or another individual, are represented as personal data within a single entry of type person; similarly, details about an organisation are represented as organizational data within a single entry of type organization.
The feed is the containing element in Atom files. The containing element has to define namespaces, so a typical first element might be something like:
Of these, portfolio, categories, and some uses of leap2 are not true namespaces, but abbreviations used as part of CURIEs.
To distinguish between versions of Leap2A, all versions apart from the 2009-03 must have a leap2:version element.
http://www.leapspecs.org/2010-07/2A/
This indicates the current stable version.
Mandatory sub-elements of feed, according to the Atom spec, are
It makes sense for the id element to be a unique URI which acts also as the base of the URIs of each entry. (See below for more detail.) The title can be anything - but it could be meaningful and help to indicate what kind of output it is. The updated date should relate to the date and time of export - either the date and time at which it was requested, or the date and time at which it was actually carried out, if this is not the same. This gives, for example,
http://www.example.ac.uk/interop/atom.aspx/webfolio/57736 Portfolio Items2008-07-16T11:11:45+00:00
It makes a great deal of sense to have the author represented at the feed level, so that the element does not have to be placed in each individual entry (unless authored by someone else).
Theophilus Thistledown
The preferred way of adding any other information about the author, including e-mail, is to use the atom:uri element to point to a person entry for the author. See the author relationship. However, for compatibility with Atom, it should also be possible to put the author's e-mail address in the atom:email sub-element of author.
The specification also says that there should be a link element with rel="self", such as
The sense of this will depend on how the portfolio system is set up. If there is an actual URL which will deliver this portfolio information to those appropriately authorised, then certainly that is the URL which should go in this element. However, there may well not be such a URL. To head off processing problems, it would then be acceptable to duplicate the id in this element, as is done here. Of course, the id may also be set to a URL which renders the same information; but if, for instance, the live URL contains a long query string, it might be easier to read to have a relatively short id URL. The value of link rel="self" does not belong directly with the imported portfolio information, but may be presented to the user in some other way.
That is all that is needed in the feed element, and leaving them out may cause problems for importing systems. There are other sub-elements of feed, but they may be ignored by importing systems.
Principles of how Leap2A relates to Atom
- As Leap2A is based on Atom, Leap2A is intended not to specify anything that is explicitly contrary to Atom. Atom constructs are used where appropriate unless there are clear problems in doing so.
- Leap2A feeds should be able to be processed acceptably by non-Leap2A Atom consumers, with the accepted loss of Leap2A-specific information that cannot reasonably be represented in Atom.
- Leap2A is not designed to use all of Atom's features and elements, particularly where Atom offers more than one way of representing the same information. In the generally accepted sense, Leap2A is an application profile of Atom. This is to minimise the variability in Leap2A and to make it easier to implement.
- Systems implementing Leap2A should only use the Atom constructs specified in Leap2A for export, and not other Atom constructs that are not specified in Leap2A.
- Leap2A systems are of course free to import other Atom constructs in any way that seems appropriate for their system.
- Where appropriate, we should try to come to agreement about how to interpret Atom constructs not specified in Leap2A in terms of those that are specified within Leap2A. This has been done in some cases.