LEAP relationships

Part of LEAP 2.0 > Constructs

Introduction
In the LEAP 2.0 model, information is organised in discrete, reusable packages, rather than in tree structures. This gives immensely more flexibility in terms of what is related to what. In the old-style hierarchical models like IMS LIP, most information related to an element had to be included within the element. But in this information model, each separable part of the portfolio information is free-standing.


 * In old-fashioned terms, each item of portfolio information is an entity, and we need to specify the relationships.
 * In Semantic Web terms, each item of portfolio information is a resource, and we need to specify the predicates.
 * In UML terms, each item of portfolio information belongs to a class, and we need to specify the associations between classes.

Relationships in LEAP 2.0
See the LEAP predicates page for details of relationships and other properties or attributes.

See the LEAP classes page for details of what the classes are.

General relationships between the general types of part
These relationships are normally fall-back relationships which would be used only if a more specific relationship, between more specific types of part, are not defined. "Is part of" has a natural inverse, "has part", which is not listed here separately, but is implied.

Detailed relationships between the detailed parts
(Omitting the generic relationships in the table above, to be elaborated)

Relationships with other people
Recording relationships between the individual who is the focus of a portfolio and other people may be taken from XFN for example. Note that a relationship is typically between on (or sometimes more) personalities of the portfolio subject and one (or sometimes more) personalities of the other individual. If the other individual has defined personalities for themselves, the URL used for the other should if possible specify the personality, not the individual as a whole.

Relationships with organisations
Here what is required is a vocabulary to define the role someone can play in an organisation. It seems unlikely that a general-purpose vocabulary could cover the myriad possible roles and role definitions, more likely would be that each organisation published a vocabulary of the roles it recognises. This might come, for example, from a company handbook.

If, as is currently likely, no published relevant corporate definitions of roles exist, roles need to be described as text.

Implementation
See
 * LEAP as XHTML and RDFa
 * LEAP relationships as RDF

Relationship vocabulary sources

 * Dublin Core
 * RDF & RDFS
 * OWL, the Web Ontology Language
 * Google Data

UKLeaP relationships for comparison
See also the mapping of parts between UKLeaP and LEAP 2.0 This is the original table prepared for UKLeaP in May of 2004, and published in the draft for public consultation. It is given here for reference only!

'This is not part of LEAP 2.0!'