From CETISwiki

Belongs to the 2009-03/Leap2A specification > predicates

This page specifies relationships between portfolio items, or entries.

Relationships between items are normally represented using atom:link sub-elements of relevant atom:entry elements. There are two 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.

For relationships using atom:link

• the rel attribute is a URI referring to the relationship type. URIs for the relationships are defined by the 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.

Contents 1 Author 2 relation 3 alternate 4 Reflection 4.1 reflects on 4.2 reflected on by 5 Whole-part 5.1 has part 5.2 is part of 6 Support and evidence 6.1 supports 6.2 supported by 6.3 has evidence 6.4 is evidence of 7 For meetings 7.1 has agenda 7.2 is agenda of 7.3 has outcome 7.4 is outcome of 7.5 attended by 7.6 attends 8 Threads 8.1 has reply 8.2 in reply to 9 Attachments 10 Use of CURIEs

Author

 <author>
   <name>Mark Pilgrim</name>
   <uri>http://example.org/</uri>
   <email>f8dy@example.com</email>
 </author>

(Example taken from the Atom documentation.)
Atom requires every entry to have an author. 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 authors left out of entries. The atom:author element is an atom person construct that must have a name, can have an e-mail address and can have a URI. If there is a separate person entry defined for that person, the URI should be the (internal) URI of that person entry. E.g.

   <uri>portfolio:person_153</uri>

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

This is a relationship, as if the author has a person entry attached, the internal URL of that entry should be used as the author uri.

If there is no URI, the author could be considered more as a literal.

relation

Note: rel="related" is Atom, not Leap2A, given in page 22 of the Atom spec. As in other cases, Leap2A prefers native Atom where it is defined.

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

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

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

alternate

This is an Atom relationship, specifically to be used to identify a file or other resource that provides an alternate, equivalent, representation of the content of a resource entry. Use:

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

Reflection

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="leap:reflects_on" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#reflects_on" href="..." />

Inverse: reflected on by

reflected on by

<link rel="leap:reflected_on_by" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#reflected_on_by" href="..." />

Inverse: reflects on

Whole-part

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.

• leap:display_order must have an integer value, but these values do not have to be consecutive.
• leap: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.

has part

<link rel="leap:has_part" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#has_part" href="..." />

or, to indicate an ordered part:

<link rel="leap:has_part" leap:display_order="2" leap: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="leap:is_part_of" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#is_part_of" href="..." />

or, to indicate being an ordered part of something:

<link rel="leap:is_part_of" leap:display_order="2" leap: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.

supports

<link rel="leap:supports" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#supports" href="..." />

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

supported by

<link rel="leap:supported_by" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#supported_by" href="..." />

Inverse: supports

has evidence

<link rel="leap:has_evidence" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#has_evidence" href="..." />

Inverse: is evidence of

is evidence of

<link rel="leap:is_evidence_of" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#is_evidence_of" 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="leap:has_agenda" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#has_agenda" href="..." />

Inverse: is agenda of
Can degrade to supported by.

is agenda of

<link rel="leap:is_agenda_of" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#is_agenda_of" href="..." />

Inverse: has agenda
Can degrade to supports.

has outcome

<link rel="leap:has_outcome" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#has_outcome" href="..." />

Inverse: is outcome of
Can degrade to supports.

is outcome of

<link rel="leap:is_outcome_of" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#is_outcome_of" href="..." />

Inverse: has outcome
Can degrade to supported by.

attended by

<link rel="leap:attended_by" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#attended_by" href="..." />

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

attends

<link rel="leap:attends" href="..." /> or <link rel="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#attends" href="..." />

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

Threads

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:

xmlns:thr="http://purl.org/syndication/thread/1.0" 

(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.

Attachments

Nothing was specified in this 2009-03 version of Leap2A specifically for attachments. See the working proposals as part of the Leap2A relationships page.

Use of CURIEs

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

xmlns:leap="http://wiki.cetis.ac.uk/2009-03/Leap2A_predicates#" 

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

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

in place of the example given above for supports.

---

• This page was last modified 06:26, 25 February 2010.
• This page has been accessed 1,288 times.
• Content is available under a Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales Licence.
• Privacy policy
• About CETISwiki
• Disclaimers