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.
- The Atom Threading Extensions specifies a non-link relationship for in reply to.
- An authorship relationship can be given through an atom:author element containing a uri linking to the author entry. See author.
- The contribution relationship is similar, through atom:contributor. See contributor.
For relationships using atom:link
- the rel attribute is a URI referring to the relationship type. URIs for the relationships are defined here in this relationships page. For readability, it is preferable to place the rel attribute before the href attribute.
- the href attribute refers to the related resource. Atom specifies that this must be an IRI, but for this specification it should normally be an http URL pointing to the id of the entry within the current set of portfolio information.
- relationships should wherever possible have link elements at both of the items at the ends of the relationship. That is equivalent to saying that relationships should be given for each portfolio item represented in the portfolio information.
- relationships may also be defined to resources not present in the portfolio information transferred.
Atom envisages author and contributor elements as Atom person constructs, like this:
<author> <name>Mark Pilgrim</name> <uri>http://example.org/</uri> <email>email@example.com</email> </author>
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 http://www.icmje.org/ethical_1author.html.
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="..." />
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.
- Atom License Extension rfc 4946
- "The IRI specified by the link's href attribute SHOULD be dereferenceable to return a representation of the license. The license representation MAY be machine readable."
- Creative Commons licences in Atom, which gives the example:
<feed xmlns="http://www.w3.org/2005/Atom"> . . <link rel="license" type="application/rdf+xml" href="http://creativecommons.org/licenses/by-nc/2.5/rdf" /> <entry> . . <link rel="license" type="text/html" href="http://creativecommons.org/licenses/by/2.5/" /> </entry> </feed>
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.
<link rel="leap2:reflects_on" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/reflects_on" href="..." />
Inverse: reflected on by
reflected on by
<link rel="leap2:reflected_on_by" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/reflected_on_by" 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.
- leap2:display_order must have an integer value, but these values do not have to be consecutive.
- leap2:when_added must have a date value in the same format, with the same restrictions, as for the published and updated elements.
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.
<link rel="leap2:has_part" href="..." />; or <link rel="http://www.cetis.org.uk/leap2/terms/has_part" 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="http://www.cetis.org.uk/leap2/terms/is_part_of" 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="http://www.cetis.org.uk/leap2/terms/supports" href="..." />
<link rel="leap2:supported_by" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/supported_by" href="..." />
<link rel="leap2:has_evidence" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/has_evidence" href="..." />
Inverse: is evidence of
is evidence of
<link rel="leap2:is_evidence_of" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/is_evidence_of" href="..." />
Inverse: has evidence
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.
<link rel="leap2:has_agenda" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/has_agenda" href="..." />
is agenda of
<link rel="leap2:is_agenda_of" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/is_agenda_of" href="..." />
<link rel="leap2:has_outcome" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/has_outcome" href="..." />
is outcome of
<link rel="leap2:is_outcome_of" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/is_outcome_of" href="..." />
<link rel="leap2:attended_by" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/attended_by" href="..." />
<link rel="leap2:attends" href="..." /> or <link rel="http://www.cetis.org.uk/leap2/terms/attends" href="..." />
These are supported natively by Atom Threading Extensions.
<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="http://www.cetis.org.uk/leap2/terms/supports" href="..." />