LEAP predicates

Part of LEAP 2.0, together with LEAP classes

=About this page= These definitions are subject to development and change, as many of them have not yet been worked in to any operational specification. Some of them have been taken up by the 2009-03/Leap2A specification as literals or relationships, and that gives those ones extra weight.

This page serves to provide URIs and brief definitions for LEAP predicates. Many LEAP predicates are modelled on better established ones, and in any implementation, the better established ones may be used instead of the LEAP ones.

As in Dublin Core, many of these predicates are related hierarchically. A triple with a sub-predicate implies, in meaning at least, the triples with the same subject and object, with the sub-predicate replaced by its super-predicate. However, predicates at different levels sometimes represent their objects differently: e.g. sometimes structured as classes, sometimes plain text, and allowance is needed for possible conversion between different representations.

There are some cases of a class appearing in the domain of a sub-predicate when it was not given in the domain of the super-predicate. This would mean either that the class would not normally take the super-predicate, as the specified sub-predicate(s) is/are the only relevant parts; or that the super-predicate would normally be too general to be useful.

Domains and Ranges, if not specified by the particular predicate, are inherited from super-predicates.

In the hierarchical list below, Capitalized Terms are used for grouping or heading, and are not defined for LEAP, while terms in all lower case, starting with "#", are the actual ones defined. (Including the '#' makes it much easier to write the page with links!)

=Alphabetic list= This table gives equivalent or near-equivalent terms from other significant specifications. Ones in italics are less definite, or not equivalent but only similar. The individual relationship names are linked to their own place in this page.

=Hierarchical list= Essential metadata Identifiers Relationships where the object is not literal
 * 
 * (basic)
 * (basic)
 * (basic)
 * 
 * 
 * (basic)
 * 
 * 
 * 
 * (basic)
 * 
 * (basic)
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * (basic)
 * 
 * (basic)
 * (basic)
 * 
 * 
 * 
 * (basic) (the most general relationship)
 * (basic)
 * 
 * 
 * (basic)
 * 
 * 
 * 
 * 
 * 
 * 
 * (basic)
 * 
 * 
 * (basic)
 * 
 * 
 * (basic)
 * (basic)
 * 
 * 
 * 
 * 
 * 
 * 
 * (basic)
 * 
 * 
 * 
 * 
 * 
 * 
 * (basic)
 * (basic)
 * Relating patterns
 * to other items
 * 
 * 
 * to external counterparts
 * 
 * 
 * 
 * 
 * Relating people and bodies to things
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * Relating people and bodies to each other
 * 
 * 

=Essential metadata=

These are attributes, fields, or literal properties of items, which (probably) do not involved a relationship with another separate item. Many of these map directly to Dublin Core terms.

type
Definition: the type of an item is its class, drawn from LEAP classes

Same as: rdf:type (URI)

Instance of: rdf:Property

Domain: item

Range: LEAP class URI

Note: See LEAP classes

created by
Definition: an item is created by the agent primarily responsible it

Same as: dc:creator (URI)

Refines: dc:contributor (URI)

Refines:

Domain: item

Range: agent; text literal (with name of agent)

Inverse:

Note: The name of the creator can be represented simply as a text field. Where the creator is not the portfolio holder, it is recommended that there should be one or more agent entries, which are objects of this predicate. Anything that does not have an explicitly named creator is assumed to be created by the creator of the nearest containing element (if the information is in XML format) or by default by the portfolio holder.

title
Definition: a short text label given to the item to help its identification

Same as: dc:title (URI)

Domain: item

Range: text literal

Note: This is the same very straightforward requirement as in almost all information systems, to have a piece of text which serves to indicate what it is, and can appear on screen in lists to be selected.

description
Definition: A description of the thing pointed to by the item

Same as: dc:description (URI)

Refines:

Domain: achievement; activity; agent; pattern; resource; selection;

Range: text literal, URL, or resource

Note: Description should only be used when the item is of a kind which describes some particular kind of thing. For entries, as well as plain items, should be used. As in Dublin Core, the description need not necessarily be given in plain text. To avoid confusion, the use of and description together should be avoided.

See also: LEAP describing things.

summary
Definition: A summary or pr&eacute;cis of the content

Same as: dc:abstract (URI)

Domain: item

Range: text literal

Note: Semantically, this is different from the. A summary simply gives a short version of the same material as the content (or description), whereas the intent has a different meaning.

date rec
Definition: a date/time relevant to the recording and disseminating process

Same as: dc:date (URI)

Refines: none

Domain: item

Range: text literal

Note: Use date rec if properly formatted dates are not available; can be used to make a note of any or all subpredicate dates. For dates referring to the real world subject of the content or description, use date ref. All of these dates refer to the record, not to the subject matter of the record. If something is written about an event, the dates associated with these predicates will be to do with the writing, revision and publishing process, not the event being written about.

created
Definition: date/time at which the item was first created

Same as: dc:created (URI)

Refines:

Domain: item

Range: W3C DateTime Note carefully that this is the date of creation of the record, that is, the LEAP item, not the date of creation of whatever it is that is referred to by the LEAP item.

modified
Definition: date/time at which the item was changed

Same as: dc:modified (URI)

Refines:

Domain: item

Range: W3C DateTime

issued
Definition: date(time) at which the item was published or made public

Same as: dc:issued (URI)

Refines:

Domain: item

Range: W3C DateTime

Note: This is used for publication date. Care is needed to avoid possible confusion between the publication date of the (portfolio) record, and the publication date of a resource being referred to by the record. For a resource, issued should refer to the publication date of the resource. For any other item that has been made public, issued should be the date on which the item was first made public.

coverage
Definition: see dc:coverage

Same as: dc:coverage (URI)

Domain: achievement; activity; agent; entry; goal; pattern; resource;

Range: text literal

Note: This would only be used for text versions of the coverage. Any formatted dates, etc., should be represented under the dates of temporal coverage, as below.

temporal
Definition: the temporal characteristics of the subject matter of the item, not designed for machine processing

Same as: dc:temporal (URI)

Cf: Google's gd:when

Refines:

Note: The temporal (coverage) is a text field describing one or more dates relevant to the subject matter, in a human-readable manner. If dates are formatted to be machine-processable, the predicate, or its refinements, should be used instead. Google's gd:when only provides for start and end. Target date is so important to PDP process (for plans and goals) that gd:when is inadequate. For activity, and particularly in planning applications, refined dates are needed, to allow earliest and latest planned start and finish. See also the encoding schemes Period and W3CDTF.

spatial
Definition: see dc:spatial

Same as: dc:spatial (URI)

Cf: Google's gd:where, which refers to GeoRSS.

Refines:

Note: spatial is envisaged as a predicate for various classes.

date ref
Definition: a structured date relevant to the subject matter of the item

Refines:

Domain: achievement; activity; agent; entry; goal; resource;

Range: W3C DateTime

Note: This has a different name to distinguish it from dc:date. dc:date refers to dates in the lifecycle of the resource, whereas date ref refers to dates relevant to the content. This is close in meaning to Dublin Core's temporal content, but rather than temporal's default text field, the date ref is a structured machine-readable date. The date ref might be referred to in the content, or could be thought of as a reference date.

start
Definition: a date(time) at which the subject matter of the item started, or is envisaged as starting

Cf:

Refines:

Domain: activity; agent; assertion; resource;

Range: W3C DateTime or achievement

Note: If it is desired to record more about the creation of something, for example the place, then use an achievement item.

start earliest
Definition: the earliest date(time) at which the subject matter of the item may have started, or is envisaged as starting

Refines:

Domain: activity;

Range: W3C DateTime

start latest
Definition: the latest date(time) at which the subject matter of the item may have started, or is envisaged as starting

Refines:

Domain: activity;

Range: W3C DateTime

end
Definition: a date(time) at which the subject matter of the item ended, or is envisaged as ending

Cf: MIAP CDD Achievement Award Date

Refines:

Domain: achievement; activity; agent; assertion; goal; resource;

end earliest
Definition: the earliest date(time) at which the subject matter of the item may have ended, or is envisaged as ending

Refines:

Domain: activity; goal;

end latest
Definition: the latest date(time) at which the subject matter of the item may have ended, or is envisaged as ending

Refines:

Domain: activity; goal;

target
Definition: the date(time) at which the subject matter of the item is intended to end

Refines:

Domain: achievement; activity; goal; plan;

activetime
Definition: the time spent actually engaged in an activity.

Domain: activity;

Range: ISO 8601 duration.

Note: This is useful for activities that are carried out intermittently. The total active time is the actual time spent on this activity, or sub-activities, but not different activities. This is not a subpredicate of dc:temporal, because dc:temporal is defined by the start and end points.

See also Leap2A activetime.

content
Definition: the main bulk of information associated with the item

Subpredicates:

Domain: item, (but NOT achievement; activity; agent; pattern)

Range: text literal, URL, or resource

Note: The content is the bulk of, say, a blog or diary entry. This could be anything, and does not necessarily describe anything else in particular. Therefore it is not the same as a "description", being rather more general. To avoid confusion, the use of content and together should be avoided, though can be effectively used alongside content. Where content is used, descriptions beyond a summary can be added by using with entry.

See also: LEAP describing things.

intent
Definition: the purpose, reason, or rationale for an item, or the subject matter of an item

Domain: achievement; activity; organization; entry; goal; resource; selection;

Range: text literal

Note: The intent is a key part of several items. It is the agent responsible for the item that is the source of the intent. For achievements, activities, goals and organizations, the intent refers to the intent of the subject matter. For entries and selections, the intent refers to the intent of the entry or the selection.

progress
Definition: the stage reached by an activity or a plan at the time of recording

Domain: activity; plan

Range: controlled vocabulary

Vocabulary: Note: There are several instances in IMS LIP where status indicators are used. The strategy for LEAP 2.0 is to use a clearer version of the same kind of thing, if there is a definite need.
 * planned
 * progressing
 * completed

Extra terms which may be useful in some contexts are:
 * possible
 * paused
 * abandoned

status
Synonym for

Personal information
There is scope for predicates to point to literals about but we are awaiting guidance on this.
 * names
 * addresses
 * other contact details

=Identifiers=

id
Definition: an identifier string at least unique to the item in context: ideally globally unique

Same as: dc:identifier (URI); xml:id; rdf:ID; atom:id and iCal:uid

Domain: item

Range: URI

Note: In terms of RDF, this is not a predicate at all, because RDF uses the id as the string to refer to the item either as subject or as object. Because RDF requires a URI, LEAP in turn requires any serialisation or binding to provide a URL to identify each item, which is then used when the information is transformed into RDF.

same as
Definition: the very same resource or item

Same as: owl:sameAs

Refines:

Domain: item;

Range: item; external resource

Note: should be used just to indicate that the resource is the actual same resource, not that it is another different representation of the same resource. Because patterns are inherently unbound to particulars, it makes no sense to say that two patterns are the same as each other. Patterns may, rather, be.

reflexive; symmetric; transitive.

different from
Definition: two concepts or patterns that need to be differentiated to avoid confusion

Same as: owl:differentFrom

Refines: nothing

Domain: item;

Range: item; external resource

Note: Different from is disjoint from and from, but different from is only needed in a few cases, to differentiate something that could be confused. It is not expected to be widespread. Different from should not be taken to refine, as it is a refinement of a lack of relation, not a refinement of a relation.

=Relationships in general=

relation
Definition: the item is related in an unspecified way to another item or the subject of a URI

Same as: dc:relation (URI)

Refines: nothing

Domain: item

Range: item; any URI

Inverse: relation (symmetric)

Note: This is the most general relationship predicate. This conforms with DC and avoids confusion with skos:related, which means something different. The direction of this relationship is not significant. Normally, when one resource relates to a second, the second may be expected to relate to the first.

=Relating items to items and externals=

Containment
Containment covers firstly the strict whole-part relationship between things of the same kind, and secondly selection of things. These are similar, but not identical. On the one hand, achievements, activities, organizations, selections and resources can be structured into parts, where the parts are of the same kind, and the relationship is structural and inherent. On the other hand, selections include a relatively arbitrary set of any items, selected for particular attention, treatment, or presentation. This is independent of a structural relationship between the whole and the part. Because "has part" and "is part of" are thought of differently by different people and for different purposes, they need to cover both of these kinds of relationship. The disadvantage of this is that the range and domain are relatively unconstrained.

If more constrained relationships are wanted, "includes" is defined here specifically for selections (or things acting like selections), This ties in nicely with "excludes". If strictly inherent structural containment is wanted, we need another predicate, which is called here "is component of" along with "has component". Component parts here are required to be of the same type as the component whole. Most things can have inherent parts of the same type, but not individual people, nor (in the view here) goals. Any suggestions for better names considered, before this is adopted into wider use.

Compare the UML terms "aggregation" and "composition". UML aggregation might be seen as somewhat closer to "includes" and "included in", while UML composition may be considered closer to "has component" and "is component of". However, the concepts cannot be mapped together, as they are used quite differently.

has part
Definition: what is referred to by the first item includes, in any sense, what is referred to by the second

Cf.: dc:hasPart (URI)

Refines:.

Domain: achievement; activity; entry; organization; goal; pattern; resource; selection;

Range: item;

Inverse:

Note: This is a general relationship, not necessarily inherent or structural.

is part of
Definition: what is referred to by the first item is included, in any sense, by what is referred to by the second

Cf.: dc:isPartOf (URI)

Refines:.

Domain: item;

Range: achievement; activity; entry; organization; goal; pattern; resource; selection;

Inverse:

Note: This is a general relationship, not necessarily inherent or structural.

has component
Definition: what is referred to by the first item has, as a structural and inherent part, what is referred to by the second

Refines:.

Domain: achievement; activity; entry; organization; pattern; resource; selection;

Range: achievement; activity; entry; organization; pattern; resource; selection;

Inverse:

Note: Things only have components of the same general type.

is component of
Definition: what is referred to by the first item is a structural and inherent part of what is referred to by the second

Refines:.

Domain: achievement; activity; entry; organization; pattern; resource; selection;

Range: achievement; activity; entry; organization; pattern; resource; selection;

Inverse:

Note: Things are only components of other things of the same general type.

included in
Definition: the item is included in the selection

Refines:.

Domain: item

Range: selection

Inverse:

Note: The selection is made up from items selected at will.

includes
Definition: the selection includes the item

Refines:.

Domain: selection

Range: item

Inverse:

Note: The selection is made up from items selected at will.

excludes
Definition: the item is specifically excluded from the selection

Refines:.

Domain: selection

Range: item

Inverse: (not needed)

Note: This may be used if a selection is defined intensionally rather than extensionally (e.g. with a query). The excludes predicate allows exclusion of some of the items from the intensional list.

Sequencing
These relationships should be used between components which are all part of the same selection. "follows" and "precedes" can only be used when there is an inherent sequence between the items, true whatever selection they appear in. If this is not true, then the sequencing should be given only within the selection itself.

follows
Definition: one item follows another if it comes immediately after in all contexts.

Same as: atom:link rel="previous"

Refines:.

Cf: dc:replaces (URI). However, the semantics of "replaces" and "follows" are different.

Domain: item

Range: item

Inverse:

Note: This is in the sense of following immediately, therefore is not transitive.

precedes
Definition: one item precedes another if it comes immediately before in all contexts.

Same as: atom:link rel="next"

Refines:.

Cf: dc:isReplacedBy (URI) However, the semantics of "isReplacedBy" and "precedes" are different.

Domain: item

Range: item

Inverse:

Note: This is in the sense of immediately preceding, therefore is not transitive.

first
Definition: where one thing has several parts, the thing's first part is either the one which does not follow any other one, or the most important part.

Same as: atom:link rel="first"

Refines:.

Domain: achievement; activity; organization; goal; resource; selection;

Note: Where the containing or presenting entry itself does not act as the first or front page, this can be a link from the container or presenter to the item that does so.

Support
Supporting is quite a general relationship between items. A typical example is of activities supporting goals and achievements. Supporting is a bit like the inanimate equivalent of contributing to. One thing supports another if it is at least a factor in the realisation of the other thing, or if it is needed for the realisation of the other thing. The supporting thing lies somewhere in a causal chain (perhaps imagined or assumed, but at least so in the view of the portfolio holder) leading to the supported thing.

supported by
Definition: A is supported by B if B is somewhere in the causal chain which leads up to A.

Refines:.

Domain: item

Range: item

Inverse:

supports
Definition: A supports B if A is somewhere in the causal chain which leads up to B.

Refines:.

Domain: item

Range: item

Inverse:

Agenda and outcomes
Refine: Support

Very often, meetings (and sometimes other activities which may not be classed as meetings) have agenda or goals, and outcomes or minutes. Logically, the agenda comes before the meeting, and therefore can be seen to support the meeting, whereas the outcomes or minutes are consequences of the meeting, and therefore can be seen as supported by it. Both agenda and minutes are sometimes represented as a block, sometimes individually. These predicates are designed to support both representations, though a system that represents each item separately will have more possibilities - for example to note actionability of particular items by individual people.

An issue arises if agenda are set as goals. The goal would then be supporting the meeting; but presumably the meeting is designed to support the attainment of the goal. It seems acceptable to have a goal both being agenda for a meeting, and being supported by that meeting.

Any self-contained item can be a topic of discussion, and therefore an agenda item. One or more agenda items could be represented as a entry, with as the agenda or minutes. If the system attaches agenda or minutes to the meeting, and has no separate details of them, then an item would be an appropriate representation.

Most things could potentially be seen as outcomes of some activity. Outcomes of an activity are seen as direct outcomes. If activity A is a direct causal influence on B, which is a causal influence on C; and if the causality all runs through B, then A can be said to have outcome B, but not outcome C.

A course may have an ability as a designed and intended learning outcome. But this is the only kind of way that any pattern can be an outcome. On a personal level, any outcomes of an activity should rather be represented as an achievement. Then, it could be that the achievement an assertion, which the portfolio holder's ability. This gets things straight - short cuts, while they may be understandable, are liable to be confused.

has agenda
Definition: a meeting has A as agenda if A is (or is intended to be) a topic of discussion in that meeting.

Refines:

Domain: meeting

Range: any item as itself; an item (probably entry) as an agenda note

Inverse:

is agenda of
Definition: A is agenda for a meeting if A is (or is intended to be) a topic of discussion in that meeting.

Refines:

Domain: any item as itself; an item (probably entry) as an agenda note

Range: meeting

Inverse:

has outcome
Definition: A has outcome B if A is one of the immediate causal factors resulting in B

Refines:

Domain: activity

Range: any item as itself; an item (probably entry) as a note or minute

Inverse:

Note: A meeting (or broader activity) may have as outcome an entry representing a minute or other formulation of an outcome. See discussion above.

is outcome of
Definition: A is an outcome of B if B is one of the immediate causal factors resulting in A

Refines:

Domain: any item as itself; an item (probably entry) as a note or minute

Range: activity

Inverse:

Note: An entry representing a minute may be an outcome of a meeting (or broader activity). See discussion above

claims
Definition: an assertion may claim an ability that is being applied to the portfolio holder Refines:.

Domain: assertion

Range: ability

Note: The substance of the claim can be in the assertion, with the ability simply indicating the area of the claim. For qualifications, it is simpler to use qualified, as the claim is inherent in the record of the holder having the qualification.

Referral
Referral occurs independently of a direct supporting relationship. A supporting relationship may or may not explicitly refer, and a referring relationship may or may not also be supportive. Referral includes bibliographic referencing, but also any other kind of referral including linking to or just mentioning.

referred to by
Definition: A is referred to by B if B mentions A or identifies A in any way

Refines:.

Domain: item

Range: item

refers to
Definition: A refers to B if A mentions B or identifies B in any way

Refines:.

Domain: item

Range: item; any URI

Referencing (bibliographic)
Refine: Referral.

Referencing here means bibliographic or academic referencing or citation, which an explicit and formal kind of referral. The Dublin Core term clearly covers bibliographic referencing.

referenced by
Definition: A is referenced by B if B contains a formal or structured reference to A

Cf: dc:isReferencedBy (URI)

Refines:

Domain: entry; resource;

Range: entry; resource;

Attachment
Refine: Referral.

Attachment is an odd relationship. It is one where there is no clear semantic relationship between the thing attached and what it is attached to, but there is plenty of established practice both paper-based, and to do with e-mails and blogs, and we all know what it means. It isn't really a kind of containment, but rather a kind of reference.

has attachment
Definition: An entry can have attachments that are not given in the content of the entry, but separately contribute to the entirety of the message.

Refines:

Domain: entry;

Range: resource;

Inverse:

is attachment to
Definition: A file is an attachment to an entry or message if it is a separate part supporting the meaning of the entry, and referred to by the entry.

Refines:

Domain: resource;

Range: entry;

Inverse:

Replying and threading
Refine: Referral.

This is intended for use with comments, discussions and other similar features. Replies held as portfolio information should be able to include the features of a entry, so that is what is the norm for domain and range.

has reply
Definition: A has reply B if B was written as a reply to, response to, or otherwise in the context of A

Cf: Atom Threading Extensions link rel="replies"

Refines:

Domain: entry; resource;

Range: entry; resource; URI of an external post, entry, or any authored work

in reply to
Definition: A was written in reply to B if A was written as a reply to, response to, or otherwise in the context of B

Cf: Atom Threading Extensions thr:in-reply-to (thr: namespace)

Refines:

Domain: entry; resource;

Range: entry; resource; URI of an external post, entry, or any authored work

Note: could also be named "is reply to", but "in reply to" is a very common phrase, perhaps short for "was written in reply to".

Reflection
Refine: Referral.

Reflection is a very common idea in personal or professional development, and being a "reflective practitioner" is a valued goal. The reflection relationship starts from a record on which someone is reflecting. The expression of the thoughts they have on reflection are then connected by these relationships to the original record. There are no obvious limits to what can be reflected on, but the reflection needs to be represented as the kind of entry which is essentially a personal expression, not a description of something.

reflected on by
Definition: A is reflected on by B if B expresses reflective thinking on A

Refines:.

Domain: item;

Range: entry; resource;

Inverse:

reflects on
Definition: A reflects on B if A expresses reflective thinking on B

Refines:.

Domain: entry; resource;

Range: item;

Inverse:

Presentation
Refine: Referral.

Several types of item refer to a particular thing or event (achievements, activities, agents, goals, patterns). Thus they cannot present something else, as their main subject is already defined. For the relationship to be one of presentation, there must be an intent to present what is presented. A photograph (resource) can present something in the sense of representing it; a collection of photographs perhaps even more so. Something can be presented if and only if it can be described - a presentation is an alternative description. Things that have content and not description present themselves: though they can be summarised.

presented by
Definition: A is presented by B if B is an item which has item A as a substantial subject

Refines:.

Domain: achievement; activity; agent; goal; pattern; resource;

Range: entry; resource; selection;

Inverse:

See also: LEAP describing things.

presents
Definition: A presents B if A is an item which has item B as a substantial subject

Refines:.

Domain: entry; resource; selection;

Range: achievement; activity; agent; goal; pattern; resource;

Inverse:

Evaluation
Refine: Referral.

The idea of evaluation goes beyond just comment and reference, to offer some kind of judgement, assessment, or other evaluation of something. Even saying "that was pretty good!" is an evaluation. For portfolio purposes, it is probably good to stay with things that are obviously and frequently evaluated, as listed here. It may be safer not to evaluate agents as a whole, but rather what they have done; and it makes little practical sense to evaluate a concept. An entry would be the most obvious item to act in this evaluating role, but it could also be a resource standing in as entry (e.g. a web page, external blog entry, word processed file) or, for a very detailed evaluation, it may need to be a selection.

evaluated by
Definition: A is evaluated by B if B is an item which offers some assessment of item A

Refines:.

Domain: achievement; activity; entry; resource; selection;

Range: entry; resource; selection;

Inverse:

evaluates
Definition: A presents B if A is an item which has item B as a substantial subject

Refines:.

Domain: entry; resource; selection;

Range: achievement; activity; entry; resource; selection;

Inverse:

Evidence
Refine: relation.

Evidence is not quite the same as causality, because rather than physical consequences we are talking about reasonably consequences in terms of belief. What is taken as, or counted as, evidence is partly subject to agreement - one can see this in relation to legal concepts. (Note that for the concept labels we use the word "evidence" as a noun, not a verb.)

Strictly, and typically of assessment, evidence is only for something concrete (achievements, activities), or something whose veracity may be doubted (assertions). There is a weaker use of the term evidence, referring to evidence of a pattern, which should rather be represented by.

Thus, if a portfolio wants to suggest a connection between an achievement and an ability, the recommended representation is
 * either that the achievement the ability
 * of that the achievement an assertion, which  the ability.

has evidence
Definition: A has evidence B if B is regarded as reasonably enhancing a person's belief in A

Refines:

Domain: achievement; activity; assertion;

Range: achievement; activity; entry; resource; selection; external resource

Inverse:

is evidence of
Definition: A is evidence of B if A is regarded as reasonably enhancing a person's belief in B

Refines:

Domain: achievement; activity; entry; resource; selection;

Range: achievement; activity; assertion;

Inverse:

=Relating patterns=

Patterning
A pattern may be embodied in many ways and many places. For portfolio purposes, activities and achievements may embody patterns of ability while activities may embody patterns of assessment.

is pattern of
Definition: A pattern is a pattern of any specific real thing or event, or other pattern, which is covered by that pattern

Refines:

Domain: pattern;

Range: achievement; activity; entry; goal; resource; selection; external resource

Inverse:

has pattern
Definition: Something has a pattern if it is an example or instance of the pattern

Refines:

Domain: achievement; activity; entry; goal; resource; selection;

Range: pattern;

Inverse:

Patterns and their external counterparts
There is a good mapping between these and the SKOS Mapping Properties.

equivalent
Definition: the two concepts or patterns can be interchanged for the practical purposes of the owner or creator of this pattern

Cf: skos:closeMatch

Refines:

Domain: pattern;

Range: external resource

Note: The meaning could be expanded thus: "all things in the real world which are important to us and come under our pattern also come under their linked pattern, and nothing else which is important to us comes under their linked pattern". Now that SKOS has closeMatch and exactMatch, it is clear that equivalent is the same as skos:closeMatch. This predicate, equivalent (in this sense) is not transitive, so that individual systems are free to define their own equivalence, rather than relying on the equivalences of others.

overlap
Definition: two patterns or concepts overlap if they share some, but not all, embodiments / instantiations

Cf: skos:relatedMatch

Refines:

Domain: pattern;

Range: external resource

Note: Do not be confused by the fact that "related" in SKOS is different from "relation" in DC. "Instantiations" in the definition here is nothing to do with classes and instances! It is to do with which particular embodiments are instances of a pattern.

satisfied by
Definition: A is satisfied by B if any requirement for A is satisfied by the provision of B

Cf: skos:narrowMatch (URI)

Refines:

Domain: pattern;

Range: external resource

Note: Informally, one interpretation of this is that B is at least as good in all ways as A. The external resource is expected to be of the same type as the pattern. The type of intended example here is that a qualification to degree level in a subject satisfies a requirement for a qualification at school level in the same subject. There seems no reason to exclude other examples of skos:narrower from this same concept.

satisfies
Definition: A satisfies B if any requirement for B is satisfied by the provision of A

Cf: skos:broadMatch (URI)

Refines:

Domain: pattern;

Range: external resource

Note: Informally, A is at least as good in all ways as B. The external resource is expected to be of the same type as the pattern. If A is at least as good as B in most, but not all, ways, then it would be a case of overlap.

=Relating people and bodies to other items= Because the types of entity at each end of these relationships do not overlap, the easiest and simplest approach might have been to have symmetric relationships which can be applied in either or both directions. Unfortunately, this idea is compromised by the fact that the long-established Dublin Core relationships are only resource metadata, not person metadata: they link from resources to people but not the other way round.

Publication
These are intended mainly to relate resources and organizations.

published by
Definition: (common sense - refer to dictionary)

Same as: dc:publisher (URI)

Refines:

Domain: item

Range: agent

Inverse:

publishes
Definition: (common sense - refer to dictionary)

Refines:

Domain: agent

Range: item

Inverse:

Contribution
The related DC element is dc:contributor. Because DC doesn't consider people as subjects, the inverse relationship is not in the normal DC terms. Contribution is seen as a general and somewhat vague concept relating an agent to any other item, particularly including resources, activities and achievements. It can naturally be seen as a kind of support, where the support is given by an agent.

contributes to
Definition: an agent contributes to any item for which they share responsibility

Refines:

Domain: agent

Range: item

Inverse:

contribution by
Definition: an item has a contribution by any agent who shares responsibility for it

Same as: dc:contributor (URI)

Refines:

Domain: item

Range: agent; or item describing the agent or agents

Inverse:

Refinements to contribution
Refine: Contribution

Attendance at a meeting can be face-to-face or otherwise mediated. Attendees are those who, by any means, discuss the agenda and agree on the outcomes.

attended by
Definition: (common sense, part of the idea of a meeting)

Cf: Google's gd:event.attendee is similar, but may not be an exact match.

Refines:

Domain: meeting; course

Range: person; item listing attendees; text literal

Inverse:

attends
Definition: (common sense, part of the idea of a meeting)

Refines:

Domain: person

Range: meeting

Inverse:

creates
Definition: an agent creates any item for which they are primarily responsible

Refines:

Domain: agent

Range: item

Inverse:

Note: The relation, 'creates', is not in DC as they do not consider people as subjects of metadata, but in practice it may only be necessary to note this relationship to resources not represented alongside their creators. This relationship is only represented separately because it might be misleading to use dc:creator to represent it. Otherwise, if we didn't have dc:creator, both could be adequately represented by a single relationship of 'creation'.

has collaborator
Definition: an item A has collaborator agent B if B collaborates with others in the creation of A

Refines:

Domain: achievement; activity; entry; goal; resource; selection;

Range: agent

Inverse:

Note: This relationship is not intended for use between people and people.

is collaborator on
Definition: an agent A is collaborator on item B if A intentionally collaborates with others in the creation or performance of B

Refines:

Domain: agent

Range: achievement; activity; entry; goal; resource; selection;

Inverse:

managed by
Definition: an activity A is managed by agent B if B has overall responsibility for A, and manages the work of one or more other people in the execution of A

Refines:

Domain: activity; qualified

Range: agent

Inverse:

manages
Definition: an agent A manages an activity B if A has overall responsibility for B, and manages the work of one or more other people in the execution of B

Refines:

Domain: agent

Range: activity; qualified

Inverse:

sponsored by
Definition: an activity A is sponsored by agent B if B provides resources to enable the execution of A

Refines:

Domain: activity

Range: agent

Inverse:

sponsors
Definition: an agent A sponsors an activity B if A provides resources to enable the execution of B

Refines:

Domain: agent

Range: activity

Inverse:

Certification, validation, attestation
Certification is not the same as. Whereas evidence connects two things that are (or are presumed to be) causally related, Certification is little to do with causal relations, and relates only an agent to a thing which can be certified. However, the things which can be certified, like the things for which there can be evidence, are those things which can have happened, or not, or be true, or not. Thus certification can in some situations be taken as evidence.

certifies
Definition: an agent A certifies an item B if A believes that B is the work of the stated creator, and/or that the content of B is true inasmuch as it can be known to be true Refines:

Domain: agent

Range: achievement; activity; assertion;

Inverse:

Note: Certification, attestation etc. imply that everything that could reasonably be checked by the agent certifying it has been checked.

certified by
Definition: an item A is certified by an agent B if B believes that A is the work of the stated creator, and/or that the content of A is true inasmuch as it can be true Refines:

Domain: achievement; activity; assertion;

Range: agent

Inverse:

Note: Certification, attestation etc. imply that everything that could reasonably be checked by the agent certifying it has been checked.

Ownership
Ownership is a tricky concept, but one that is widely used in various ways. For the purposes of LEAP 2.0, the concept is left undefined, beyond indicating that some rights in the item are claimed by the agent. One would often expect ownership rights to include: viewing, copying, exploiting, modifying and deleting, and determining the permissions of others to take these actions.

owns
Definition: A owns B means that agent A claims at least some key rights associated with item B

Refines:

Domain: agent

Range: item

Inverse:

Note: if owns is used in relation to a resource, it may implies that the agent owns the resource as normal property. People or organizations may own other organizations in this way, as well. If it is used in relation to any other kind of item, it implies that the agent has some intellectual property rights in the record, or takes responsibility for the record.

owned by
Definition: A is owned by B means that item A has at least some key rights that are claimed by agent B

Refines:

Domain: item

Range: agent

Inverse:

Note: see note on.

Permission
See the section on permissions in the background.

Employment
One cannot properly define employment of a person by an agent as a single predicate, because it would not connect with the essential temporal (and other) aspects of employment. Best to do it, instead, through an activity being in the employ of an agent. This has certain legal and IP implications, of course, which are valuable to have recorded. If a period of employment by itself is to be recorded, as for a CV, simply describe the period as an activity, and add an "in employ of" relationship.

in employ of
Definition: an activity is carried out in the employ of an agent who has a formal and legal employer relationship with the employee(s) carrying out the activity

Refines:

Domain: activity

Range: agent

Inverse: not needed - it would be something like "paid money to have this done".

=Predicates relating agents to each other=

known as
Definition: The name by which the person is known to the holder

Refines:

Domain: person

Range: text literal

Note:

knows me as
Definition: The name and/or ID by which the holder is known to the agent

Refines:

Domain: agent

Range: text literal

Note:

=Predicates for use with blank nodes= The introduction of personal data in Leap2A has clarified the need for some structured data, which will naturally be represented in RDF using blank nodes.

=Additions=

To add a predicate, one needs to
 * decide where it belongs in the structure
 * put a main entry for it there, including
 * definition
 * what it is a refinement of
 * domain (subject) types, if different from super-predicate
 * range (object) types, if different from super-predicate
 * put a link in the, noting where it is similar to other definitions
 * put a link in the appropriate place in the
 * go to the domain LEAP classes noted and add it there
 * go to the range LEAP classes and add it there
 * click through to the class pages and add it there in a little more detail.

=Notes=

For references, see also the LEAP references.

Calling these "predicates" links to Semantic Web concepts and RDF. In older data models, there were the concepts of attributes and relationships, which were seen as distinct. Even now, in UML models, attributes of classes are represented differently from related classes. In the Semantic Web, predicates, sometimes called "properties" for ease of comprehension, relate resources equally both to other resources as values and to literal values. Some values are normally literal values - for instance dates - but other values could be literal values or other resources as values.

For Semantic Web vocabulary, there is a page on OWL and RDFS documentation with index.

A good reference for Dublin Core terms is the DCMI Metadata Terms page. Note that Dublin Core is not designed to include the representation of people or bodies. Relationships between resources normally have inverse relationships included in Dublin Core, but relationships between resources and people, etc., do not: these will have to be defined. Dublin Core modified their approach, 2008-01, so that there is no longer a distinction between elements and terms - they are all terms.

SKOS is progressing well towards W3C Recommendation status, and now has very useful predicates, many of which have exactly matching predicates here. The SKOS reference document now has a 2008 revision.

Google Data seems worth exploring, and has been used by Nottingham and other institutions in trials.

Atom itself has a few useful relationship predicates - see the list of all of the officially recognised ones