This document discusses competence structures for portfolio tools. It notes that portfolios are used to evidence competence and skills. Competence areas have different skills that may be arranged hierarchically. There is common ground among how tools and competence areas are treated that could allow for reuse. A common format is needed to define and communicate competence structures between tools. The meeting aims to share how tools currently handle structures, find areas of agreement on a common model, and discuss next steps for supporting interoperability work.

1. Competence structures
for portfolio tools
Simon Grant
JISC Centre for Educational Technology
and Interoperability Standards (CETIS)
Telford
2010-10-21

2. Portfolios evidence competence
 (and skill, etc. etc. let's not worry at this stage about the terminology)
 Portfolio (and related) tools often assist learners to
evidence their attainment in areas of competence
 Several reasons
 self-tracking of attainment; action planning
 formative or summative assessment
 presentation to others
 Many different areas of ability
 Each area has a different set of skills etc.
 Some of these are arranged hierarchically

3. There are large overlaps
 There is much common ground among the ways
 different tools work
 different areas of ability are treated

4. Common interest in reuse
 There is a common interest in being able to
 reuse the same tool in different ability areas
 deal with the same ability area using different tools
 To do this, we need to decouple tools and ability areas

5. Communicating structures
 To create structures in one place, then use them in
another
 they should be defined in a common format
 so that the structures can be
 output
 communicated
 input
 automatically by relevant tools.

6. Exposing the structures
 When a suitable format is agreed
 structures and their parts can be given URIs
 handled by web servers to deliver
 human readable information for people
 machine processable information for other systems
 to be used as links e.g. in portfolios
 so that definitions don't need to be duplicated
 so that automatic matching can be done

7. Aims of today's meeting
 Share how current tools handle such structures
 Clarify the points in common
 Try to find some agreement on common model
 Agree requirements for interoperability
 Suggest next steps for progress
 Consider what needs to be done with Leap2A
 Introduce JISC plans to support this work

8. Issues arisen in discussion
 searching for other comparable competencies
 who is it for?
 can we say that a result is the result of an assessment
process intended to assess a particular competency?
 how do we integrate with Leap2A?
 what really belongs to assessment, not to the definitions?
 how do we integrate with claims?
 hive off domain specific stuff into Leap2A
 need to document use cases
 pedagogical stuff

9. Possible features of single
definitions
 title
 description
 URI / identifier
 DC terms
 assessment method
 assessment criterion
 verification required or can
be self-assessed
 prerequisites
 co-requisites
 similarity relationships
 rating (comment on quality of
skill)
 weighting
 context and equipment
 type (knowledge/behaviour,
skill, etc) in terms of a stated
category scheme
 status
 evidenced by
 level (in terms of a stated
scheme)

10. Possible features of structures
 title
 description
 URI / identifier
 DC terms
 order
 composition relationships
 3rd party mapping
 mandatory
 identity with external definition

11. Defining bodies
e.g.
 Sector Skills Councils
 universities
 awarding bodies
 professional bodies
 employers
 industry associations