Competence structures and portfolio tools

722 views
656 views

Published on

presentation at Telford on 2010-10-21

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
722
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Competence structures and portfolio tools

  1. 1. Competence structures for portfolio tools Simon Grant JISC Centre for Educational Technology and Interoperability Standards (CETIS) Telford 2010-10-21
  2. 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. 3. There are large overlaps  There is much common ground among the ways  different tools work  different areas of ability are treated
  4. 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. 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. 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. 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. 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. 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. 10. Possible features of structures  title  description  URI / identifier  DC terms  order  composition relationships  3rd party mapping  mandatory  identity with external definition
  11. 11. Defining bodies e.g.  Sector Skills Councils  universities  awarding bodies  professional bodies  employers  industry associations

×