InteropAbility

See the web site and within it, the specification itself

The Researcher Development Framework page works through the example of Vitae RDF comparing a possible InLOC treatment with two implemented treatments within InteropAbility.

A detailed mapping of the InteropAbility spec to InLOC will be at the InteropAbility mapping page.

Introduction

InteropAbility was a UK project, funded by JISC, running from February to July 2011. Its specified aims were

  • to develop an information model and specification to represent competence structures focusing on use by e-portfolio tools;
  • to represent a range of competence structures using this specification;
  • to carry out sufficient prototype development work on partner systems in order to:
    • demonstrate the use of the draft specification, and
    • provide guidance on implementation in e-portfolio systems.

The spec gives an information model and XML binding for communicating either individual "ability" definitions, or structures, with minimal differences between representing definitions and structures.

The spec was successfully implemented in prototype by the collaborating partners.

General information

information details
Name / title of source/model and version if applicable InteropAbility
Stakeholder InterCom project consortium (see web site)
URL http://www.interopability.org/
Orientation (work, education, etc.) Mainly learning, education and training.
Explicit model or implicit model? Explicit information model – see below for UML.
Can organisations have competence? No.
Number of people currently affected The consortium that developed InteropAbility has very many end users of portfolio tools.
Sectors covered Any sector.
User communities The direct users of the spec are the developers of portfolio tools that handle skills or competences.
Significant use cases Technical use cases described in final report. See below.
Significant business cases  
Sample materials Small sample of XML included in final report. Several other extensive examples available, including two attached: ResDevFra0-5.xml and 1295_ResDevFra.xml which are both alternative representations of the Vitae RDF.
Key features influencing their uptake of InLOC outputs This is a completed project that inputs to InLOC, not that InLOC can influence.

Features

(see the Features page or the separate pages for each feature)

N Features ? notes
00 More than one model 1 includes two very similar models – see below
01 Identifiers 1 for both interopAbility and ability elements
02 Hierarchy (internal) 1 hasSubAbility / isSubAbilityOf
03 Internal relationships 1 isRelatedTo see below for other possibilities
04 External relationships 1 isExactMatchOf see below for other possibilities
05 Conditionality / optionality 1 spec gives isOptionalPartOf, but no examples yet use this
06 Text syntax 0  
07 Structured identifiers 0 structure is neither specified nor disallowed
08 Classification 1 modelled on Atom – no particular categories specified, though "skill", "knowledge", "behaviour" are suggested as examples
09 Level attribution 1 educationLevel, as in Dublin Core, with no specified structure
10 Level definition 1 scale – see below
11 Context   The interopAbility structure gives context to contained ability items
12 Evidence and assessment 1 exemplaryEvidence is barely used in the examples – intention is to describe the kind of evidence that is appropriate, not particular evidence
13 Extensions 0 no specific provision for extensions, but not explicitly constrained
14 Profiles 0 nothing explicit
15 Adaptation 1 versioning possible through suggested relationships "isNewVersionOf" and "isOldVersionOf" but no examples given
16 Definition by example 1 possible within the scale structure – see below
17 Learning resources 1 allows links to relevant resources
18 Learner records 0 designed to be referred to from learner records
19 Multilinguality 0 no explicit provision

Further information

Stakeholders within InteropAbility

The companies that collaborated to create this specification include:

Two models or one?

From the final project report, paragraph 20:

The InteropAbility approach is to include the structure as part and parcel of the competence definition itself: the consortium agreed for practical purposes on the view that, in relation to frameworks, an individual competence is contextualised by the structure (if any) within which it sits. As a result, this means that we took the view that competence and structure are different aspects of the same thing and as such are inseparable. The structure is the mechanism by which competences are related. Therefore, in information management terms, there is an ‘ability’ that is usually related to one or more other abilities via defined relationships. In many cases these will be of the narrowerThan / broaderThan type, though other types are readily envisaged.

and paragraph 28:

A framework could be defined as “An ordered group of competencies brought together for a purpose”. However, as a competence may be hierarchical and therefore might ‘include’ other competencies, a framework could be conceptualised as a competence in its own right, thereby equating competence and competence framework. This would have the advantage of simplifying any technical information structure and allow for frameworks themselves to be included within their own structures.

The specification names the containing element "interopAbility" whereas the contained abilities (at any depth) are named "ability". Thus there are in fact two slightly different models, though InteropAbility minimises the difference between them, attempting to avoid in particular having a separate identifier for a structure that simply breaks down a particular ability into its constituent parts.

The elements interopAbilityTitle and interopAbilityDescription are allowed within the interopAbility element, in case there is a need for the structure to be described differently from its main component ability.

Use cases

  1. User can describe individual competence within a scheme
  2. User can indicate competence order within the context of a scheme
  3. User can describe scores or weighting for competences
  4. User can indicate requirement for self-assessment at competence level
  5. User can reference competence schemes against a level scheme
  6. User can indicate requirement for verification at competence level
  7. User can describe cumulative relationships between competences within schemes
  8. User can describe competence scheme hierarchy or groupings as required
  9. User can define a relationship between single competences for one or more schemes
  10. User can indicate relationships between schemes

Relationships

The spec gives:

The following vocabulary is an initial recommendation for types of relationship; subject to further testing and discussion in communities of practice:

but in the examples given alongside the specification, only the bold ones appear to have been used so far.

relationship inverse notes
hasSubAbility isSubAbilityOf cf. broaderThan / narrowerThan
hasUnit isUnitOf relating sub ability to a higher level ability
isOptionalPartOf    
leadsTo leadsFrom  
requires isRequiredBy  
isEvidencedBy    
isRelatedTo    
isExactMatchOf    
isNearMatchOf    
isPartialMatchOf    
isNewVersionOf isOldVersionOf  

Scales

The Scales feature allows the spec to represent abilities that have points on any scale – i.e. that have various levels.
A scale element has

  • forUser (optional, text)
  • lowerBound (optional, numeric)
  • upperBound (optional, numeric)
  • purpose (optional, text)
  • scaleItem – this describes one or more points on the scale
    • key (numeric)
    • value (descriptive)

In examples, it seems that the ability description is used to explain the points on the scale.

UML

Guidelines requirements

Duality of definition / framework

The fact that InteropAbility put much effort into this suggests that a very clear and extensive discussion is needed, covering InteropAbility's "interopAbility" and "ability" elements.

Scales and levels

The InteropAbility "scale" has several features in common with other level structures, but done in their own way. A detailed explanation and clarification will be appropriate.


InLOC consultation with InteropAbility is through Simon Grant.