2009-03/Leap2A types

• has reply → entry
• in reply to → entry
• is evidence of → items that can have evidence
• reflects on → items that can be reflected on
• supports → plan
• supported by → plan (as the plan's goal)

• learning cycle
• SWOT
• life area
• common item

Any entry without an explicit type should be interpreted as of this type: it is the default type. Thus, when importing a plain Atom blog feed, all the entries should be handled as if they are of this type.

OR: information about a self-defined and self-claimed ability

• has part → ability
• is part of → ability
• has evidence → evidential items
• reflected on by → entry

Ideally, abilities are handled as follows, which is the first case:

• impersonal definitions of ability are defined outside the portfolio, typically in a skills or competency framework
• they can also be defined inside the portfolio, as long as they are authored not by the portfolio holder
• the portfolio contains claims (which are entries) to abilities and plans to attain abilities
• evidence of any kind can be linked either to a claim, in its support, or directly to the ability, as more general evidence

However, this first case does not make sense for abilities that are defined, claimed and evidenced by the holder. So we distinguish a second, self-defined case, where the ability entry contains the name (or very short definition) of the ability as the title, and the description of the ability, along with any claim or description of evidence, in the content. In this second case, the ability must be authored by the holder, which it will be by default if no author element is present.

• date point="end" = the actual date at which the achievement was accomplished
• date point="target" = the date planned for completion, if wanted for comparison

• has evidence → evidential items
• is evidence of → items that can have evidence
• reflected on by → entry

• life area

• date point="start" = date activity started or is planned to start
• date point="end" = date activity ended or is planned to end
• date point="target" = date by which activity should be completed
• activetime = time actually spent engaged with activity
• spatial = place or location or address of activity
• status = planned, progressing or completed
• persondata id = id with the organization that supports this activity

• has evidence → evidential items
• reflected on by → entry
• has part → activity
• supported by → organization

• priority
• life area

Start and end dates are central to activity records. In the case of an activity, the start and end are the overall dates or times. Even if an activity does not have explicit start and end dates represented, being an activity type will clearly indicate that the item is to be treated as an activity. Particularly if dates are missing, the status will say whether it is future, present or past. Persondata id elements record the id for the portfolio holder connected to this activity, which may for instance be a period of study, employment, or membership. For this to work, there will need to be exactly one organization that "supports" this activity.

• date point="start" = scheduled or actual start time of meeting
• date point="end" = scheduled or actual end time of meeting
• spatial = place or location or address of meeting
• status = planned, progressing or completed

• has agenda → any appropriate
• has outcome → any appropriate
• attended by → person or entry listing people
• supported by → plan or resource
• reflected on by → entry

• life area

Meetings can either be records or be calendar or diary items. Systems claiming to be able to import meetings must make sensible use of time and place information provided.

• orgdata = contact information and other data about the organization
• spatial = postal addresses, or text description of the spatial/geographical scope of the organization

• supports → activity

The "activity" supported by an organization can be simply a record of membership or affiliation. At present, this is not given a separate type in Leap2A. Organizations can have units as their parts, but we will try to avoid the idea that a person can be literally "part of" an organization. Systems may or may not hold information about organizations separately. Often, names of educational institutions or employers will be given simply as names, and recorded as part of the title or content of activities.

• persondata = various CV-related and contact information.
• spatial = postal addresses

• attends → meeting
• author ← entry

• person type

Also, all other relevant people can be listed with as much or as little personal information as appropriate. A person as defined here can be the author of any entry. If there is more than one person defined in a Leap2A export, it is essential that the feed author is linked to the person entry for the portfolio holder.

• date point="start" = scheduled or actual starting date of this plan
• date point="end" = scheduled or actual end date of this plan
• date point="target" = date by which goal should have been attained
• status = planned, progressing or completed

• has part → plan or activity
• is part of → plan
• supported by → entry
• supports → entry, which is the goal of this plan
• reflected on by → entry

• priority
• life area

The plan describes the way to achieve the desired situation. It answers the question "how are you going to achieve this goal?" There may be a plain piece of text describing the plan, or how the parts of the plan are articulated (the content of the plan), and there may be linked activities or goals (or possibly entries) as parts. Plans typically have a target date: the date on which the goal is meant to be achieved.

• summary = short summary/description of a file
• content =
  1. reference to file using atomOutOfLineContent construct
  2. list of resources
  3. description of non-included resource
  • do not use atomInlineOtherContent constructs

• is evidence of → items that can have evidence
• reflected on by → entry
• alternate → alternate representation of the same content

• resource type

• a file, web resource, or other electronic resource
  • either given in the content as text, html or xhtml
  • or referred to as the content "src" (in this case the mime type should be given), and
    • either included as a file packaged with the export, with the src attribute giving the relative address in the package
    • or available on the web at a URL given in the src attribute of the content
  • a short, summary description may be given in the summary element
  • any alternate form of the resource may be represented as a link, with the attribute rel="alternate"
• a plain text note of resources of any kind where the content lists the resource(s)
• a description of a non-electronic resource, or a resource that is not directly available for inclusion, attachment or linking. In this case, the atom:type should NOT be the mime type of the resource. The mime type of the resource may be described in the (text) content.

Note that other items can also play the role of resources, and this will be obvious by their relationship (generally "supports") to the main item under consideration. Where there is an entry of type person who supports something, that may be interpreted in the context of that item as a resource of type people. Where there is an entry of type selection supporting something, the selection may be given a resource category, and thus be equivalent in meaning to a plain text list resource with the same category and equivalent content. In each case, if there is only one resource, or the resources are of the same type, the entry may be given a resource type category. If there are different types of resource mixed together, the resource type may be left out, or given as "Unclassified". Care needs to be taken to distinguish between information about the resource (its meaning, etc.) and records relating to the entry (metadata). Resources authored by the portfolio holder can be the artefacts that are evidence of their abilities.

• summary = optional summary of the content, or of the parts of the selection
• content may be required or not, depending on selection type

• has part → any
• is part of → selection

• selection type

This type could also be called collection or presentation, all of which are central in portfolio thinking, as portfolio items are typically collected, then selected for use in presentations. Selections exist only in virtue of what is in them, so there should be no ambiguity in giving the relationship as has part. The whole-part relationship should be used only for immediate parts. If A is part of B, and B is part of C, A should not also be given as part of C. A summary of this type of entry may refer more specifically to the rationale for the selection, but the content or description, if any, will be taken to refer to all of the parts as well as possibly the selection itself, as with a blog collection or feed. If the selection as such has no content, it may be presented by an entry, which may or may not be part of the selection.

Note also that the selection type is not the only way of representing hierarchical structure or nesting. The types #activity and #plan can also contain parts of the same type, and if there is a hierarchical structure to be represented that naturally fits the activity or plan type, that is strongly preferred to using the selection type.

• author
• title
• published, updated
• content: this normally contains the main text associated with the item
• summary: this is not required, but if used should give just a summary of the content, as is the intention in Atom

• relation
• is part of → selection