This page specifies relationships between portfolio items, or entries. These are mostly implemented with the use of the atom:link element.


Relationships between items are normally represented using atom:link sub-elements of relevant atom:entry elements. There are three exceptions.

For relationships using atom:link

Atom relationships

author, contributor

Atom envisages author and contributor elements as Atom person constructs, like this:

  <name>Mark Pilgrim</name>

An author must be identifiable for every entry; contributors are optional. If the author is not defined for a particular entry, it is inherited from the feed author, where it has to be defined if there are any entries without an author element. The atom:author and atom:contributor elements are an atom person constructs that must have a name, can have an e-mail address and can have a URI. For Leap2A purposes, if there is a separate person entry defined for that person, the URI of the author or contributor element referring to that person should be the (internal) URI of that person entry. E.g.


If there is no person entry, the URI may be a personal URI in the sense envisaged in FOAF, etc., as in the Atom example.

When the URI element of the author or contributor is used in Leap2A, it is equivalent to having an authorship or contributor relationship between the item and the person item representing the author or contributor. Were it not for Atom having this construct, we would have defined relationships within Leap2A. If there is no URI, the authors or contributors could be considered more as literals.

For a definition of what authorship and contributorship entail, see


Atom recommends this for the Atom feed element, defining it as "the preferred URI for retrieving Atom Feed Documents representing this Atom feed." For Leap2A, if there is a URI that can deliver this feed (or, later, an updated version with similar content) then it is recommended to have this URI in the self link element for the feed. However, as this is not always the case, having a <code>link rel="self"</code> remains optional for a Leap2A feed.

Within an atom:entry, it is allowed though not explicitly recommended in the Atom documentation. In Leap2A, the URI of a Leap2A/resource or Leap2A/publication on the Web should be given with link rel="self". Atom documents:

The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.


= atom related

NOTE: the concept of this relationship is referred to as "relation", following the Dublin Core dcterms:relation (URI]), but in the rel attribute of atom:link (and thus in actual Leap2A XML) it is written as rel="related".

<link rel="related" href="..." />

Inverse: relation
This is the basic default relationship, and is non-directional, simply asserting that a relationship exists. Use this if nothing can be reliably represented about the nature of the relationship.

This is the relationship to be used between non-resource and resource items in cases where a resource iten is "attached" without any more specific role or meaning. The resource item entry is then linked to the actual attached file with an Atom link rel="enclosure".

For discussion of the terminology used, please see this e-mail topic


This is specified in Atom as a related resource. In Leap2A its use is restricted to linking entries directly with attached files, as described in Leap2A/files, Leap2A/resource, and content. When using "enclosure" in Leap2A, the type and length attributes of the link are recommended but not mandatory.


This is specified in Atom, specifically to be used to identify a file or other resource that provides an alternate, equivalent, representation of the content of an entry. Its use is discouraged in Leap2A, except to provide translated entries of any kind, in which case the hreflang attribute should be used.



<feed xmlns="">
  <link rel="license" type="application/rdf+xml" href="" />
    <link rel="license" type="text/html" href="" />

If anyone decides to implement this within Leap2A, they are requested to inform and consult the rest of the Leap2A community, so that common practice can be established. The license link is for machine-processable information only – for human-readable information, use the rights literal.


These relationships were considered to be needed to clarify which entries or other types of record express reflections on which other ones. Typically they are used to connect two things where the user interface invites the user to enter their reflections on something.

reflects on

<link rel="leap2:reflects_on" href="..." /> or <link rel="" href="..." />

Inverse: reflected on by

reflected on by

<link rel="leap2:reflected_on_by" href="..." /> or <link rel="" href="..." />

Inverse: reflects on


The relationships here are very general purpose, and include two closely related concepts. One is structural or inherent whole-part relations, generally between items of the same type, and the other is the relation between a selection (collection, presentation, etc.) and its components. This includes relating blog feeds and CVs to the entries that make them up. CVs are in essence a selection of other information.

The basic relationships, "has part" and "is part of", work for unordered selections. Where ordering is needed, for example to represent the order of entries in a blog, either or both of two extra new attributes are added.

Display order and when added must be represented identically at both ends of the relationship.

In terms of the paper, Representing Order in RDF, this approach would appear to be closest to the "ternary" option.

In a multi-level whole-part hierarchy, part relationships must only be represented between adjacent levels: the whole-part relationship is only immediate, not transitive. Thus, if A has part B, and B has part C, A must NOT have part C. The necessity for this is even clearer where the relationship has ordering attributes.

has part

<link rel="leap2:has_part" href="..." />; or <link rel="" href="..." />

or, to indicate an ordered part:

<link rel="leap2:has_part" leap2:display_order="2" leap2:when_added="2009-02-27T07:19:30+00:00" href="..." />

Inverse: is part of
Optional attributes: display_order; when_added

is part of

<link rel="leap2:is_part_of" href="..." /> or <link rel="" href="..." />

or, to indicate being an ordered part of something:

<link rel="leap2:is_part_of" leap2:display_order="2" leap2:when_added="2009-02-27T07:19:30+00:00" href="..." />

Inverse: has part
Optional attributes: display_order; when_added

Support and evidence

These two concepts are sometimes, but not always, linked.

Supports and supported by are general contributory or causal relationships, which other more specific ones can degrade into.

The concept of evidence is well understood within PDP and portfolio practice. No particular quality or type of evidence is implied. Evidence includes entries describing or explaining what evidence there is.


<link rel="leap2:supports" href="..." /> or <link rel="" href="..." />

Inverse: supported by
Note: an organization supports any activities that belong to them.

supported by

<link rel="leap2:supported_by" href="..." /> or <link rel="" href="..." />

Inverse: supports

has evidence

<link rel="leap2:has_evidence" href="..." /> or <link rel="" href="..." />

Inverse: is evidence of

is evidence of

<link rel="leap2:is_evidence_of" href="..." /> or <link rel="" href="..." />

Inverse: has evidence

For meetings

These relationships are specifically designed for meetings, but could be used elsewhere. Any item can be an agenda item, or an entry can give a listed agenda for a meeting. Outcomes can be specific entries with the outcomes (or minutes) written down, or they can be other items, particularly plans, or potentially achievements.

has agenda

<link rel="leap2:has_agenda" href="..." /> or <link rel="" href="..." />

Inverse: is agenda of
Can degrade to supported by.

is agenda of

<link rel="leap2:is_agenda_of" href="..." /> or <link rel="" href="..." />

Inverse: has agenda
Can degrade to supports.

has outcome

<link rel="leap2:has_outcome" href="..." /> or <link rel="" href="..." />

Inverse: is outcome of
Can degrade to supports.

is outcome of

<link rel="leap2:is_outcome_of" href="..." /> or <link rel="" href="..." />

Inverse: has outcome
Can degrade to supported by.

attended by

<link rel="leap2:attended_by" href="..." /> or <link rel="" href="..." />

Can degrade to supported by.
For relating meetings to people who attend them.


<link rel="leap2:attends" href="..." /> or <link rel="" href="..." />

Inverse:attended by
Can degrade to supports.
For relating people to meetings they attend.


These are supported natively by Atom Threading Extensions.

has reply

<link rel="replies" href="..." />

Inverse: in reply to
Can degrade to supports.
This has a similar intent as in the Atom documentation, but rather than linking to another feed that contains several replies, as Atom does, here we specify one href in each link pointing directly to a single other entry, and multiple link elements if there is more than one reply. Atom has "replies" in the plural, but here it is understood as a singular "reply", so that it can be an inverse relationship to "in reply to". Other attributes of link are not expected.

in reply to

<thr:in-reply-to ref="..." ... />

Note the hyphens in the Atom Threading version of this. If this is used, the following namespace should be defined in the first element of the document:


(see , Section 3 of the Threading documentation)
Inverse: has reply
Can degrade to supported by.
This is used as a direct sub-element of an entry. Note particularly that it is the "ref" attribute, not the "href" attribute, that should be used, to stay as close as possible to the original specification.


See Leap2A/files for general guidance on how to handle files in Leap2A.

Leap2A reserves Atom's link rel="enclosure" just for linking Leap2A items (Atom entries) to attached files, that in Leap2A are in the zip archive. In the case where the attachment is significant in its own right, or significant to more than one entry, or has a meaningful title or description, the file should be wrapped in a resource entry. The link rel="enclosure" must not be used for the link from the non-resource entry to the resource entry. as that would be against the Atom usage.

There are several legitimate relationships between non-resource entries and resource entries, but if nothing more specific is appropriate, these relationships can be represented with a link rel="related".

Use of CURIEs

To use CURIEs with Leap2A relationships, you should have the leap2 namespace defined something like this


in the opening element of the XML. Then, for example, instead of the entry example, you would use

<link rel="leap2:supports" href="..." />

in place of

<link rel="" href="..." />