Part of LEAP 2.0, together with LEAP classes
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!)
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.
| spec | namespace | information |
|---|---|---|
| Atom | http://www.w3.org/2005/Atom | RFC 4287; thr: RFC 4685 |
| Dublin Core | http://purl.org/dc/terms/ | DCMI Metadata Terms |
| OWL | http://www.w3.org/2002/07/owl | OWL Reference |
| RDF | http://www.w3.org/1999/02/22-rdf-syntax-ns# | primer concepts syntax |
| SKOS | http://www.w3.org/2008/05/skos# | primer reference |
| UKLeaP | see LEAP relationships |
Identifiers
Relationships where the object is not literal
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.
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
Definition: an item is created by the agent primarily responsible it
Same as: dc:creator
(URI)
Refines: dc:contributor
(URI)
Refines: #contribution by
Domain: item
Range: agent; text literal (with name of agent)
Inverse: #creates
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.
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.
Definition: A description of the thing pointed to by the item
Same as: dc:description
(URI)
Refines: #content
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, #content should be used.
As in Dublin Core, the description need not necessarily be given in plain text.
To avoid confusion, the use of #content and description together should be avoided.
See also: LEAP describing things.
Definition: A summary or précis of the content
Same as: dc:abstract
(URI)
Domain: item
Range: text literal
Note: Semantically, this is different from the #intent. A summary simply gives a short version of the same material as the content (or description), whereas the intent has a different meaning.
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.
Definition: date/time at which the item was first created
Same as: dc:created
(URI)
Refines: #date rec
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.
Definition: date/time at which the item was changed
Same as: dc:modified
(URI)
Refines: #date rec
Domain: item
Range: W3C DateTime
Definition: date(time) at which the item was published or made public
Same as: dc:issued
(URI)
Refines: #date rec
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.
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.
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: #coverage
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 #date ref 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.
Definition: see dc:spatial
Same as: dc:spatial
(URI)
Cf: Google's gd:where,
which refers to GeoRSS.
Refines: #coverage
Note: spatial is envisaged as a predicate for various classes.
Definition: a structured date relevant to the subject matter of the item
Refines: #temporal
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.
Definition: a date(time) at which the subject matter of the item started, or is envisaged as starting
Cf:
Refines: #date ref
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.
Definition: the earliest date(time) at which the subject matter of the item may have started, or is envisaged as starting
Refines: #start
Domain:
activity;
Range: W3C DateTime
Definition: the latest date(time) at which the subject matter of the item may have started, or is envisaged as starting
Refines: #start
Domain:
activity;
Range: W3C DateTime
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: #date ref
Domain:
achievement;
activity;
agent;
assertion;
goal;
resource;
Definition: the earliest date(time) at which the subject matter of the item may have ended, or is envisaged as ending
Refines: #end
Domain:
activity;
goal;
Definition: the latest date(time) at which the subject matter of the item may have ended, or is envisaged as ending
Refines: #end
Domain:
activity;
goal;
Definition: the date(time) at which the subject matter of the item is intended to end
Refines: #date ref
Domain:
achievement;
activity;
goal;
plan;
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.
Definition: the main bulk of information associated with the item
Subpredicates: #description
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 #description together should be avoided,
though #summary can be effectively used alongside content.
Where content is used, descriptions beyond a summary can be added by using #presented by with entry.
See also: LEAP describing things.
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.
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.
Extra terms which may be useful in some contexts are:
Synonym for #progress
There is scope for predicates to point to literals about
but we are awaiting guidance on this.
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.
Definition: the very same resource or item
Same as: owl:sameAs
Refines: #relation
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 #equivalent.
reflexive; symmetric; transitive.
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 #same as and from #equivalent, 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 #relation, as it is a refinement of a lack of relation, not a refinement of a 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.
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.
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: #relation.
Domain: achievement; activity; entry; organization; goal; pattern; resource; selection;
Range: item;
Inverse: #is part of
Note: This is a general relationship, not necessarily inherent or structural.
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: #relation.
Domain: item;
Range: achievement; activity; entry; organization; goal; pattern; resource; selection;
Inverse: #has part
Note: This is a general relationship, not necessarily inherent or structural.
Definition: what is referred to by the first item has, as a structural and inherent part, what is referred to by the second
Refines: #has part.
Domain: achievement; activity; entry; organization; pattern; resource; selection;
Range: achievement; activity; entry; organization; pattern; resource; selection;
Inverse: #is component of
Note: Things only have components of the same general type.
Definition: what is referred to by the first item is a structural and inherent part of what is referred to by the second
Refines: #is part of.
Domain: achievement; activity; entry; organization; pattern; resource; selection;
Range: achievement; activity; entry; organization; pattern; resource; selection;
Inverse: #has component
Note: Things are only components of other things of the same general type.
Definition: the item is included in the selection
Refines: #is part of.
Domain: item
Range: selection
Inverse: #includes
Note: The selection is made up from items selected at will.
Definition: the selection includes the item
Refines: #has part.
Domain: selection
Range: item
Inverse: #included in
Note: The selection is made up from items selected at will.
Definition: the item is specifically excluded from the selection
Refines: #relation.
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.
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.
Definition: one item follows another if it comes immediately after in all contexts.
Same as: atom:link rel="previous"
Refines: #relation.
Cf: dc:replaces
(URI).
However, the semantics of "replaces" and "follows" are different.
Domain: item
Range: item
Inverse: #precedes
Note: This is in the sense of following immediately, therefore is not transitive.
Definition: one item precedes another if it comes immediately before in all contexts.
Same as: atom:link rel="next"
Refines: #relation.
Cf: dc:isReplacedBy
(URI)
However, the semantics of "isReplacedBy" and "precedes" are different.
Domain: item
Range: item
Inverse: #follows
Note: This is in the sense of immediately preceding, therefore is not transitive.
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: #has part.
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.
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.
Definition: A is supported by B if B is somewhere in the causal chain which leads up to A.
Refines: #relation.
Domain: item
Range: item
Inverse: #supports
Definition: A supports B if A is somewhere in the causal chain which leads up to B.
Refines: #relation.
Domain: item
Range: item
Inverse: #supported by
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 #intent 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 #is evidence of an assertion, which #claims the portfolio holder's ability. This gets things straight - short cuts, while they may be understandable, are liable to be confused.
Definition: a meeting has A as agenda if A is (or is intended to be) a topic of discussion in that meeting.
Refines: #supported by
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: #supports
Domain: any item as itself; an item (probably entry) as an agenda note
Range: meeting
Inverse: #has agenda
Definition: A has outcome B if A is one of the immediate causal factors resulting in B
Refines: #supports
Domain: activity
Range: any item as itself; an item (probably entry) as a note or minute
Inverse: #is outcome of
Note: A meeting (or broader activity) may have as outcome an entry representing a minute or other formulation of an outcome. See discussion above.
Definition: A is an outcome of B if B is one of the immediate causal factors resulting in A
Refines: #supported by
Domain: any item as itself; an item (probably entry) as a note or minute
Range: activity
Inverse: #has outcome
Note: An entry representing a minute may be an outcome of a meeting (or broader activity). See discussion above
Definition: an assertion may claim an ability
that is being applied to the portfolio holder
Refines: #relation.
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 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.
Definition: A is referred to by B if B mentions A or identifies A in any way
Refines: #relation.
Domain: item
Range: item
Definition: A refers to B if A mentions B or identifies B in any way
Refines: #relation.
Domain: item
Range: item; any URI
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.
Definition: A is referenced by B if B contains a formal or structured reference to A
Cf: dc:isReferencedBy
(URI)
Refines: #referred to by
Domain: entry; resource;
Range: entry; resource;
Definition: A referencs B if A contains a formal or structured reference to B
Cf: dc:references
(URI)
Refines: #refers to
Domain: entry; resource;
Range: entry; resource; URI of a published work
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.
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: #referred to by
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: #refers to
Domain: resource;
Range: entry;
Inverse: #has attachment
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.
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: #referred to by
Domain: entry; resource;
Range: entry; resource; URI of an external post, entry, or any authored work
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: #refers to
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".
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.
Definition: A is reflected on by B if B expresses reflective thinking on A
Refines: #referred to by.
Domain:
item;
Range: entry; resource;
Inverse: #reflects on
Definition: A reflects on B if A expresses reflective thinking on B
Refines: #refers to.
Domain: entry; resource;
Range:
item;
Inverse: #reflected on by
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.
Definition: A is presented by B if B is an item which has item A as a substantial subject
Refines: #referred to by.
Domain:
achievement;
activity;
agent;
goal;
pattern;
resource;
Range: entry; resource; selection;
Inverse: #presents
See also: LEAP describing things.
Definition: A presents B if A is an item which has item B as a substantial subject
Refines: #refers to.
Domain: entry; resource; selection;
Range:
achievement;
activity;
agent;
goal;
pattern;
resource;
Inverse: #presented by
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.
Definition: A is evaluated by B if B is an item which offers some assessment of item A
Refines: #referred to by.
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: #refers to.
Domain: entry; resource; selection;
Range:
achievement;
activity;
entry;
resource;
selection;
Inverse: #evaluated by
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 #Patterning.
Thus, if a portfolio wants to suggest a connection between an achievement and an ability, the recommended representation is
Definition: A has evidence B if B is regarded as reasonably enhancing a person's belief in A
Refines: #relation
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: #relation
Domain: achievement; activity; entry; resource; selection;
Range: achievement; activity; assertion;
Inverse: #has evidence
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.
Definition: A pattern is a pattern of any specific real thing or event, or other pattern, which is covered by that pattern
Refines: #relation
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: #relation
Domain: achievement; activity; entry; goal; resource; selection;
Range: pattern;
Inverse: #is pattern of
There is a good mapping between these and the SKOS Mapping Properties.
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: #relation
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.
Definition: two patterns or concepts overlap if they share some, but not all, embodiments / instantiations
Cf: skos:relatedMatch
Refines: #relation
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.
Definition: A is satisfied by B if any requirement for A is satisfied by the provision of B
Cf: skos:narrowMatch (URI)
Refines: #relation
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.
Definition: A satisfies B if any requirement for B is satisfied by the provision of A
Cf: skos:broadMatch (URI)
Refines: #relation
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.
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.
These are intended mainly to relate resources and organizations.
Definition: (common sense - refer to dictionary)
Same as: dc:publisher
(URI)
Refines: #relation
Domain: item
Range: agent
Inverse: #publishes
Definition: (common sense - refer to dictionary)
Refines: #relation
Domain: agent
Range: item
Inverse: #published by
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.
Definition: an agent contributes to any item for which they share responsibility
Refines: #supports
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: #supported by
Domain: item
Range: agent; or item describing the agent or agents
Inverse: #contributes to
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.
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: #contribution by
Domain: meeting; course
Range: person; item listing attendees; text literal
Inverse: #attends
Definition: (common sense, part of the idea of a meeting)
Refines: #contributes to
Domain: person
Range: meeting
Inverse: #attended by
Definition: an agent creates any item for which they are primarily responsible
Refines: #contributes to
Domain: agent
Range: item
Inverse: #created by
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'.
Definition: an item A has collaborator agent B if B collaborates with others in the creation of A
Refines: #contribution by
Domain: achievement; activity; entry; goal; resource; selection;
Range: agent
Inverse: #is collaborator on
Note: This relationship is not intended for use between people and people.
Definition: an agent A is collaborator on item B if A intentionally collaborates with others in the creation or performance of B
Refines: #contributes to
Domain: agent
Range: achievement; activity; entry; goal; resource; selection;
Inverse: #has collaborator
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: #contribution by
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: #contributes to
Domain: agent
Range: activity; qualified
Inverse: #managed by
Definition: an activity A is sponsored by agent B if B provides resources to enable the execution of A
Refines: #contribution by
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: #contributes to
Domain: agent
Range: activity
Inverse: #sponsored by
Certification is not the same as #Evidence. 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.
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: #relation
Domain: agent
Range: achievement; activity; assertion;
Inverse: #certified by
Note: Certification, attestation etc. imply that everything that could reasonably be checked by the agent certifying it has been checked.
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: #relation
Domain: achievement; activity; assertion;
Range: agent
Inverse: #certifies
Note: Certification, attestation etc. imply that everything that could reasonably be checked by the agent certifying it has been checked.
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.
Definition: A owns B means that agent A claims at least some key rights associated with item B
Refines: #relation
Domain: agent
Range: item
Inverse: #owned by
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.
Definition: A is owned by B means that item A has at least some key rights that are claimed by agent B
Refines: #relation
Domain: item
Range: agent
Inverse: #owns
Note: see note on #owns.
See the section on permissions in the background.
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.
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: #relation
Domain: activity
Range: agent
Inverse: not needed - it would be something like "paid money to have this done".
Definition: The name by which the person is known to the holder
Refines: #relation
Domain: person
Range: text literal
Note:
Definition: The name and/or ID by which the holder is known to the agent
Refines: #relation
Domain: agent
Range: text literal
Note:
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.
To add a predicate, one needs to
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
