InteropAbility Project Report Final 1.2 · Background and introduction 1. In December 2010 JISC...

InteropAbility Project Final Report

1

Project Information

Project Title Interoperable Competences Framework Specification Project (InteropAbility)

Start Date 21 February 2011 End Date 8 July 2011

Lead Institution TAG Developments, the web development division of BLi Education Ltd

Project Director Matt Wingfield, Managing Director, TAG Developments

Project Manager Alan Paull, APS Ltd

Contact email [email protected]

Partner Institutions TAG DevelopmentsAPS Ltd MyKnowledgeMap Ltd Newcastle University The University of Nottingham Pebble Learning Ltd

Project Webpage URL http://www.interopability.org/

Programme Name eLearning Programme

Programme Manager Lisa Gray, [email protected]


2

Interoperable Competences Framework Specification (InteropAbility) Project

Final Report

8 July 2011

Contents

Executive Summary ................................................................................................................. 3 Background and introduction ................................................................................................... 4 Overview .................................................................................................................................. 4

Communications ................................................................................................................... 5 Aims and objectives ................................................................................................................. 5

Aims ..................................................................................................................................... 5 Objectives ............................................................................................................................ 5

The draft information model and specification .......................................................................... 6 Methods and activities.............................................................................................................. 6

How the draft specification was developed ........................................................................... 6 Use Cases ............................................................................................................................ 8 Competence structures used .............................................................................................. 11 Using the draft specification ............................................................................................... 11 Some alternative visions ..................................................................................................... 19

Outputs .................................................................................................................................. 21 Conclusions and recommendations ....................................................................................... 21

Conclusions ........................................................................................................................ 21 Relationship to other initiatives ........................................................................................... 23 Recommendations ............................................................................................................. 23

Appendix A: Evaluation reports .............................................................................................. 25 Workshop 2 Evaluation comments ..................................................................................... 25 Workshop 3 Evaluation comments ..................................................................................... 25

Appendix B: Example of PRAM course (University of Nottingham) in XCRI-CAP format, extended to include Researcher Development Framework information ................................. 27

Acknowledgements

The Project Board consisted of:

Karim Derrick (Chairman, for TAG Learning) Shane Sutherland (for Pebble Learning) Paul Horner (for the University of Newcastle) Dave Waller (for MyKnowledgeMap) Kirstie Coolin (for the University of Nottingham) Alan Paull (for APS)

The Project Board would like to thank all those members of staff at partner organisations who played a part in the InteropAbility Project, in particular Sandra Winfield (University of Nottingham) for evaluation work, and for the support of Simon Grant at CETIS and Lisa Gray, our JISC Programme Manager.


3

InteropAbility Project Report

Executive Summary

Information about competence structures is available in the UK through a wide range of organisations, and the suppliers of e-portfolio and assessment management services use data about competences extensively within their products and services. However, this information has little common structure and few common definitions, making use of it across different organisations, software and services problematic. The InteropAbility Project addresses the need to agree on the representation of this information and has produced a draft interoperable machine readable specification, as a step towards a standard way of working.

The InteropAbility Project has brought together a consortium of key organisations responsible for many internationally respected and commonly used e-portfolio and assessment management products and services. Consortium partners have extensive practical experience and expertise in the development of information management standards, including a close involvement in linked initiatives, such as Leap2A1 and XCRI-CAP2.

The InteropAbility draft information model and specification have been developed through a highly iterative process that has produced a practical draft usable by all partners, which is now being disseminated to the wider community. At each stage of the project a revised schema was written for individual and shared prototyping and testing across the systems of partner organisations.

Discussions comparing the InteropAbility approach and other approaches were key to our decisions about the final draft model and specification. The parallel development of the draft MedBiquitous competency framework3, a health sector specific initiative, was reviewed and taken into account as part of the InteropAbility Project.

The InteropAbility draft information model and draft specification are published on the project website at: http://www.interopAbility.org/. The website includes the design goals and requirements that formed the foundation of the work, discussion points that give the rationale behind some of the detail, and a list of InteropAbility tools and exemplars on the web.

This report recommends that JISC and consortium partners:

Develop proposals for a governance model in tandem with those for Leap2A and XCRI; Consider funding further operational trials to develop the specification towards formal

standardisation, and to investigate issues to do with version control, discovery, vocabulary development and extensibility;

Encourage dissemination and the establishment of communities of practice.

The partners in the InterCom Consortium are committed to implementing the InteropAbility specification and to continuing its development. Several import and export demonstrators are available now, and some operational functionality has already been built. Each partner has indicated plans for future development to integrate the InteropAbility specification into their products and services.

The draft specification has proven to be easy to work with, easy to read and as a consequence easy to implement. Each of these considerations is essential to the success of the specification. The real power of the InteropAbility specification is in the capability to render network frameworks. The InteropAbility Project has demonstrated that capability. The next stage is to begin to explore the value of machine readable networked frameworks.

1 http://www.leapspecs.org/2A/ 2 http://www.xcri.co.uk/ 3 See MedBiquitous Competencies Working Group: http://www.medbiq.org/working_groups/competencies/index.html


4

Background and introduction 1. In December 2010 JISC invited tenders to develop an interoperability specification to

represent competence structures, so that these can be used within different e-portfolio and assessment tools. The aims of the work 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:

o demonstrate the use of the draft specification, and o provide guidance on implementation in e-portfolio systems.

2. Total funding of £30,000 was allocated, and the work was to be carried out over a period from end of February to early July 2011.

3. Complementing the work on Leap2A, a common specification to represent competence structures would enable competences to be imported into and referenced within e-portfolio and assessment tools more easily. The learner could continue to use the same e-portfolio tool through different learning episodes and phases, to evidence against different learning outcomes or assessment objectives, or could export achievement information against a competence structure into another system. Vendors would be able to develop and sell just one e-portfolio tool to support any number of different sets of skills. HEIs would be able to deploy fewer tools across the institution.

4. This report is intended to inform the reader how the draft specification came about, to discuss issues that pose challenges for implementation and to reveal the experiences of the partners in developing the InteropAbility Specification.

Overview 5. Information of the ‘competence structures’ general type is available in the UK, through

the National Occupational Standards (NOS) of the Sector Skills Councils, through awarding and accreditation bodies that publish curriculum information and assessment criteria for awards, through professional, statutory and regulatory bodies for individual development, and through Higher Education Institutions (HEIs) and sector agencies (for example the QAA) as means to document learning outcomes and benchmarking statements. In addition the suppliers of e-portfolio and assessment management services make use of this data within their products.

6. However, this information has very little common structure, and the different requirements of different organisations, products and services has resulted in different solutions to the representation and management of the information. The InteropAbility Project addresses the need to agree on the structures and definitions that are most common and most useful, so that a specification for a draft interoperable machine readable model can be developed, tested and published, as the first step towards a standard way of working.

7. In the future we envisage that organisations responsible for, or making extensive use of, competence structures, will publish their information using the specification, so that others can use it easily across all compliant e-portfolio tools, assessment management, course management and description software, career guidance and planning services.

8. The partners in the InterCom Consortium delivering the project are detailed in our project website (http://www.interopability.org/wiki/InteropAbility_Wiki) and listed here:

TAG Developments, a division of BLi Education Ltd (lead partner) APS Ltd MyKnowledgeMap Ltd Newcastle University The University of Nottingham Pebble Learning Ltd

9. Other relevant activities and projects include:

Leap2A - http://www.leapspecs.org/2A/


5

MedBiquitous Competencies Working Group: http://www.medbiq.org/working_groups/competencies/index.html

Communications

10. Project communications were handled using the Basecamp web-based project collaboration tool4. In addition the draft information model, draft specification and other main deliverables were published on the project website at http://www.interopability.org/.

Aims and objectives

Aims

11. The project aimed to develop and test a common information model and draft specification for competence structures to support individuals and organisations that need to exchange information about these structures. Building on earlier interoperability work, including the development of Leap2A and XCRI, the project’s main focus was on the potential use of the draft specification in the partners’ e-portfolio tools. Partners aimed to demonstrate the efficacy of the draft specification in the context of a range of use cases and scenarios relating to usage by consortium members.

12. The project has engaged with the wider stakeholder community as far as the tight project time scales permitted. In particular Simon Grant at CETIS was consulted and involved in discussion of key issues with the team inside and outside of project meetings, on and offline. The project is disseminating its findings, so that the draft InteropAbility specification and the project’s other outputs can form the basis of further work on interoperability standards in this domain, and so that early adopters can make practical use of the model and specification for publication of competence structures in a common format.

Objectives

13. The project’s objectives were for the partners to work closely together to develop a set of agreed outputs, building up from initial use cases and scenarios, through detailed requirements, to a common information model and an agreed draft specification. Our work focused on investigations and prototyping of an iterative draft to flush out issues and to refine it, so that it would be fit for purpose.

14. Owing to the importance of the wider stakeholder community, the project included specific dissemination and engagement activities, so that an outcome of the project can be the practical use of the specification, for example publication of competence structures on the web by organisations other than the partners. This dissemination and engagement work is ongoing, and partners will continue with it as the draft specification is further developed after the end of the project.

Objective 1: Design goals and requirements

15. The project team will describe specific use cases and scenarios in order to:

Specify and agree design goals and requirements. Ensure that an appropriate range of different uses of the competence

specification are covered, including usage in academic, vocational, professional and qualification based areas.

Objective 2: Common information model and initial draft specification

16. A common information model that meets the demands of the design goals and requirements will be drafted, in tandem with an initial draft specification. It will be concise and complete in its coverage of the problem space, but not detailed. It will be designed to support further investigations and prototyping by the partners.

4 http://www.basecamphq.com/


6

Objective 3: Final specification

17. The project team will produce and publish a final specification that is fit for purpose by the end of the project. It will be published on the web in a suitable format.

Objective 4: Dissemination and engagement

18. Project outputs and findings will be disseminated to stakeholders through existing events towards the end of the project, the project website and through JISC via formal reporting. Interim findings will be disseminated to interested parties who are not project team members, so that they can be engaged in the work.

The draft information model and specification 19. The InteropAbility draft information model and draft specification are published on the

project website at: http://www.interopAbility.org/. The information model section includes a rationale for the model that is rehearsed here.

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.

21. In our approach, defining a competence includes defining a structure, if there are relationships to sub-competences or siblings. Whether or not to define a structure becomes a matter for the author and is related to the usage to which the competence will be put. If the competence is part of an NOS, for example, then a rigorous approach to structure will be needed. If the competence is a broad-brush skill for a ‘once off’ application in an e-portfolio, for example, then it may be relatively unstructured.

22. The competence therefore has a single identifier. In many cases and for RDF and other open data usage, we naturally hope and expect that identifier to be a URI leading to human-readable and computer-consumable material of defined types.

Methods and activities

How the draft specification was developed

23. Our methodology involved creating the following ‘products’, each one building successively on the previous one:

1. Create initial use cases and scenarios, described with succinct text and diagrams, and identifying which competence structures will be used.

2. Write and agree design goals and requirements, formally described textually on the project wiki; requirements derived from existing work on Leap2A, XCRI-CAP (http://www.xcri.co.uk/), competence structures and e-portfolio tools.

3. Create and agree the initial information model and draft specification for iterative testing and revision; in the future we expect to develop a common core plus additional elements approach.

4. Produce a prototype schema to test out the model.

5. Create the final draft specification for reporting, publication and dissemination.

24. Development of the draft specification was highly iterative and involved discussions between partners both face-to-face and through posting on Basecamp. Each partner had its own perspective and its own requirements, so our discussions were necessarily ‘messier’, less formal and less structured in practice than might be apparent from this description. The bedrock of the development was a broad agreement across all partners on the common purpose – producing a practical draft specification usable by all.


7

25. Our method was scaffolded around three workshops held on 10 March 2011, 14 April 2011 and 6 June 2011. Before each workshop we drew up broad expectations of outputs and a loose format or agenda. The format and timings were not prescribed in detail, which allowed attendees to explore unforeseen areas and issues. The first workshop established an agreed approach, design goals and requirements, and enabled us to produce a first draft ‘straw man’ specification. Between the workshops each partner carried out its own testing, prototyping activities and internal discussions, producing test outputs for experimentation by other partners where possible. At the April and June workshops the partners reported on their experiences to date, enabling us to update and revise the straw man rapidly for further testing.

Defining ‘competence’ and ‘framework’

26. Rather than use the term ‘competence’, which came with its own baggage, we preferred to use the more generic term ‘ability’. This was derived from our initial working definition of ‘competence’ from the first workshop, which was “The ability to do something successfully” (but see below).

27. We agreed that different contexts required different frameworks, for example there would be richer ones for skills analysis, simpler ones for other purposes. The specification needed to be as wide as possible, so that it could cover all these contexts. There would need to be links to:

Job roles (target levels, importance levels) Assessment Qualifications (qualification as a competency framework, for example containing

‘group’, ‘block’, ‘members’) Categories, for example ‘skill’, ‘knowledge’, ‘behaviour’; there may be individual

vocabularies of categories for specific communities of practice.

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.

29. A competence that was to be re-used could be re-used entirely ‘as is’ with no changes. Or it could be copied and modified, thereby setting up a relationship with or versioning of the original.

30. Taking into account the two points above, we revised our definition of competence to: “The ability to do specified things successfully”. Furthermore this definition meant that a key to competence frameworks, and therefore to competences, was the relationships between abilities.

Data items

31. We outlined the data entities and relationships between them at the initial workshop. These are published in the project wiki as part of the information model. We also defined and refined the number and definitions of the detailed data items subsequently in the light of experience. These are published in the draft specification.

Comparison with MedBiquitous competence object and competence framework model

32. Discussions comparing the InteropAbility approach and other approaches were key to our decisions about the final draft model and specification. These were held through Basecamp, via Simon Grant’s blog and extensively during Workshops 2 and 3.

33. The approaches differed in their view about whether to construct a framework model separately from a competence model. Discussions brought the concepts closer together, and we introduced interopAbilityTitle and interopAbilityDescription elements to permit the structure to be described separately from the root ability element. However, our approach does not have the complexity of a separately identified and separately addressable framework. This enables a consuming service to consume an InteropAbility element in the same fashion as an ability element, if desired.


8

34. We suggest that the draft specification has potential advantages compared with other approaches (for example the MedBiquitous approach5) as follows, though these have yet to be rigorously evaluated:

All the information required for import is in one place with one identifier; publishing the structure effectively publishes the essential components of the competences.

It supports the creation of new frameworks, either formal or informal. It meets the design goals and requirements determined earlier. It can handle both internal relationships (to competences within the framework)

and external relationships (to competences outside the framework).

35. The project team also recognises some disadvantages and appreciates that more may emerge after further wider consultation:

The relationships may come with a lot of material not to do with the framework structure (for example categories and descriptions) that must be handled or ignored by automatic systems.

If a given competence node is specified and detailed in a structure more than once, then an importer will duplicate all the material of that node, unless an importer takes special measures to avoid this duplication.

Final prototyping and testing

36. Final prototyping and testing took place around the third Workshop and lasted until the project end date. Further work will continue after the project has finished, as the InteropAbility specification is intended to be a draft at this stage.

37. We agreed the following points as a result of our final testing:

Use well defined and unambiguous terms for relationships, for example “has sub-ability” / “is sub-ability of”; these are now defined in a draft vocabulary.

Bi-directional relationships are needed; for example an ‘isSubAbilityOf’ relation in a child element requires a ‘hasSubAbility’ relation in the parent ability, and ideally these should be confirmed by the owner of each ability.

We don’t need separate identifiers for structure and content because we identify the interopAbility element as the root on publication or grouping together of abilities.

For nested abilities, the ability could be fully included or referenced via abilityRef and the ability title.

We do not envisage handling an ability separately from its structure. Scale is part of an ability, but the scale type can be referenced in a standardised

way; in other words an ability can refer to and use an externally described scale. The interopAbility element would be the identified root element in the

specification. It would have the same properties as an ability element, but would always act as the root element.

Include a ‘resource’ sub-element in the ability element.

38. The final draft specification is as published in version 0.5 (dated 5 July 2011) on the project website. This includes an XML schema6, short fictional instance file7, and large-scale example, the Researcher Development Framework8.

Use Cases

39. The project’s relevant high level use cases are described here and formed the start of the development of design goals and requirements. This section of the report illustrates how the draft specification can be used to meet each case in turn, using various practical examples; please refer to the NOS Plumbing Unit C227 example9 and the Researcher Development Framework example8, in particular.

5 See MedBiquitous Competencies Working Group: http://www.medbiq.org/working_groups/competencies/index.html 6 http://www.alanpaull.co.uk/InteropAbility/interopAbility0.5.xsd 7 http://www.alanpaull.co.uk/InteropAbility/InteropAbilityInstance.xml 8 http://www.alanpaull.co.uk/InteropAbility/resDevFramework_revisedPart0.5.xml 9 http://www.alanpaull.co.uk/InteropAbility/NOSplumbingC227_0.4.xml


9

.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

40. User can describe individual competence within a scheme:

Supported by <title> and <description> of the InteropAbility and Ability entities.

In C227 referenced by main InteropAbility identifier, then by internal nested ability, each of which has <title> and <description>. For using step ladders (C227.1):

InteropAbility.identifier=”C227”

.ability.identifier=”C227.1”

.title=” Use step ladders to gain access beyond hand reach height”

.description=” The National Standard...”

41. User can indicate competence order within the context of a scheme:

Supported by <relationship>

Traversing the C227 <relationship> elements lists all nested internal abilities using the ‘hasSubAbility’ typeOfRelationship:

C227.1 C227.2 C227.3 C227.4

From these, more sub-abilities could be found (in fact there are no more sub-abilities in this example. Note: each of these relationships has no ‘internalOrExternal’ attribute; this default indicates that they are all internal relationships, and are therefore within this published scheme.

42. User can describe scores or weighting for competences:

Supported by <scale> In the RDF, each ability at 2nd and 3rd level uses a 1 to 5 ‘phase’ scale to rate the competence of an individual. These are held as key-value pairs in the Scale elements. For example: ‘1’ and ‘Phase 1’. Each phase is described in the ability’s description element.

43. User can indicate requirement for self-assessment at competence level

Supported by <for User> and <purpose> within <scale>

In Pebblepad forms we set a parameter which allows any particular element to be completed by:

an end user;

a peer; or

a tutor/assessor

In our new version forms will be amalgamated with profiles to make templates which will all use the InteropAbility spec; the ability to limit who can complete certain elements is very important to us – even though it is not yet available on our current profiles.


10

44. User can reference competence schemes against a level scheme

Supported by <educationLevel>, a standard dcterms entity that can be used to refer to any education level scheme.

A level could be indicated in C227 to reference the NVQ level 2, as in paragraph 46 below.

45. User can indicate requirement for verification at competence level

Supported by <exemplaryEvidence> and <forUser> and <purpose>

Precise linkage of assessment evidence to individual criteria is being developed by TAG for InteropAbility compliant assessment schemes using its Red Pen annotation and mark-up tool.

46. User can describe cumulative relationships between competences within schemes

Supported by <relationship> entities

Within C227 a system can search relationships by type, including, for example all external relationships:

Using the internalOrExternal attribute on the relationship element, the system can determine that C227 –

isRelatedTo C13, and isRelatedTo C222, and isExactMatchOf CSSC74

And in a similar fashion that C22 (Promote health, safety and welfare in active leisure and recreation) –

isRequiredBy Level 2 NVQ Certificate in Active Leisure, Learning and Well-being Operational Services

In addition, through internal relationships, a system can traverse up or down any hasSubAbility or isSubAbilityOf relationships, to establish the cumulative relationships that group together C227.1, .2, .3 and .4 into the C227 unit; bearing in mind that an ability is not just the sum of its parts.

47. User can describe competence scheme hierarchy or groupings as required

Supported by import of <InteropAbility> hierarchies or groupings of <ability> elements ‘on the fly’

For example, in a PDP context the profile Graduate Skills describes the competences typically required of a new graduate. The profile, published in InteropAbility format, is easily imported into the user’s instantiation of PebblePad and made available to students who subsequently add evidence against each ability statement.

48. User can define a relationship between single competences for one or more schemes

Supported by <relationship> and <typeOfRelationship> elements

Each ability can hold an unlimited number of relationships between itself and abilities that can be internal (within the current InteropAbility framework) or external (referenced from another framework). In the NOS C227 example, these are illustrated by relationships within the hierarchy (for example C227 to C227.1, hasSubAbility / isSubAbilityOf) and to the outside (for example C227 to C13, isRelatedTo).


11

49. User can indicate relationships between schemes

Supported by <relationship> at <InteropAbility> level

As for the previous use case, but in this case acting at the root level (C227).

Competence structures used

50. The following competence structures were used in the project:

Name of structure Partner using it

Researcher Development Framework (RDF) University of Nottingham

Qualifying Teacher Standards Pebble Learning

Newly Qualified Teacher Standards Pebble Learning

Chemistry Employability Profile Pebble Learning

Hospitality Employability Profile Pebble Learning

Learning Skills Profile Pebble Learning

Requirements for Research Students Pebble Learning

NOS Plumbing APS Ltd

Newcastle Graduate Skills Framework Newcastle University

ALPS CETL Common Competency Maps for Healthcare, Communication Skills, Team Working, Ethical Practice

MyKnowledgeMap

CIPD Professional HR Map MyKnowledgeMap

Effective Management & Leadership Skills MyKnowledgeMap

Sales Skills MyKnowledgeMap

Diabetes Care MyKnowledgeMap

Procurement MyKnowledgeMap

Chartered Engineering MyKnowledgeMap

iMedia TAG Learning

ILP (Qualifying Teacher Standards variation) TAG Learning

Using the draft specification

APS Ltd

51. APS was not directly involved in the prototyping and testing with real products, but carried out initial development, mapping and desk-based comparison work. Creation of some examples for use as instances of implementation proved instructive. In particular we mapped a unit of the National Occupational Standard for Plumbing into the later drafts of the specification, which proved a useful exercise, as nothing was left out, and no transformation or mapping was required.

52. We also gave assistance to the University of Nottingham in production of the complex Researcher Development Framework, which has subsequently been imported into PebblePad.


12

MyKnowledgeMap

Prototyping and testing

53. MKM has produced exports of a number of their key competency frameworks using a number of draft specifications throughout the development process. Some of these frameworks have incorporated the notion of shared abilities, those elements that can exist in multiple frameworks while only being defined once. Later exports of frameworks have been successfully imported into the Pebble Learning Profile tool.

54. MKM has also developed a simple online tool (built with PHP and MySQL) to support rapid creation of abilities and frameworks using the InteropAbility XML format. This tool, along with source code, will be available at http://php.mkmlabs.com/abilitybuilder/index.php and this type of tool will be very useful for further implementation testing after the end of the project.

Framework usage & InteropAbility compatibility

55. Competency frameworks, in one form or another, are in use across many MKM products and project implementations. Many of the more complex structures and frameworks were used during definition of the specification, while others have been used for practical testing of the prototype applications developed.

56. Frameworks currently in use include:

CIPD Professional HR Map ALPS CETL Common Competency Maps for Healthcare

o Communication Skills 10 o Team Working 10 o Ethical Practice 10

Effective Management & Leadership Skills 11 Sales Skills Diabetes Care Procurement Chartered Engineering

Issues

57. MKM’s main issues, when entering this process, centred around the diverse uses and contexts of frameworks across their product portfolio. It was important that any abilities and frameworks built using the InteropAbility specification would be well suited for use across the entire product range, including assessment systems, e-portfolios, competency analysis applications and MIS reporting portals.

58. Features of the specification supporting the inclusion of “lead in” text, rating / assessment scales, definition of contexts and users, as well as the diverse range of both internal and external relationships appear to provide solutions to many of these issues but this will become apparent as more testing and implementation takes place.

10 Available in part 11 Available in full


13

Figure 1: MKM's integration of InteropAbility into MyShowcase platform

Future developments

59. MKM is planning to implement the InteropAbility specification into one of their core competency services, which provides a rich user interface for the creation of frameworks. This component sits at the heart of many of MKM’s products and will allow frameworks to be downloaded in the InteropAbility format as well as being served via web-services.

60. Alongside this development, MKM will be adapting the MyShowcase personal portfolio tool (http://www.my-showcase.org) to consume frameworks in this format rather than the currently supported proprietary XML format.

61. This initial integration development will help to prove that the InteropAbility format can be successfully adopted to support a range of processes and uses and the architecture that will be adopted for this development will leave open potential for further integrations with other tools, as shown above.

Pebble Learning


62. A demonstration of importing and exporting InteropAbility specification files into Pebble Learning’s Profile builder was made available to partners for testing.

63. The import made some assumptions about the format, in order to simplify the trial implementation. These would not need to be made in a production level system.

ScaleItem's values are integers pointing to a value between the upperBound and lowerBound (if specified)

There will only be one identifier and one title per ability forUse will be either: learner, tutor, assessor, moderator (although not fully

utilised)

64. There were also some limitations:

External abilities were ignored Only relationships for leadsTo or hasSubAbility were followed Exports include all date fields whether set or not The current Pebblepad only handled up to 4 levels (profile, set, key question

and question) so if the levels were deeper than this, they were flattened. Only basic link type resources would be imported.


14

Framework availability

65. At present approximately 15 competency frameworks are made available to share between PebblePad installations. The frameworks include:

Qualifying Teacher Standards Newly Qualified Teacher Standards Chemistry Employability Profile Hospitality Employability Profile Learning Skills Profile Requirements for Research Students

66. The frameworks are available as XML documents, but do not conform to any standards, because none were extant prior to this project. As a result of the successful development of InteropAbility all of the profiles created and shared in PebblePad systems will be converted to conform to this specification.

67. Further, InteropAbility will be used to describe all template outputs in PP+, a new version of the PebblePad system due to be released in February 2012. The construct template will include both competency frameworks and standardised forms.

Practical usage

68. Typically a tutor will either create their own profiles (frameworks) or will search the existing offerings for a profile matching their needs. For example, in a Personal Development Planning (PDP) context the Graduate Skills profile describes the competences typically required of a new graduate. This profile, when defined in InteropAbility format, is easily imported into the user’s instantiation of PebblePad and made available to students, who can subsequently add evidence against each ability statement.

69. Once PP+ is released, tutors and end users will have access to a shared repository of templates, all conforming to InteropAbility, which can be directly accessed from their PP account.

Future development

70. At present the work of this project has centred on providing complete frameworks conforming to an existing requirement. We see future work with this specification allowing users to browse for ability descriptors and idiosyncratically developing their own frameworks against which they can append suitable evidence.

TAG Learning


71. TAG has to date implemented an export tool as an addition to its specification management system. This system provides a visual interface to qualification specification development and management. Originally built around an in-house version of the InteropAbility specification, the system is now being developed to include an InteropAbility export and import function.

72. In addition, TAG’s systems include less formal mechanisms for creating assessment schemes ‘on-the-fly’. These schemes can be used for the purpose of formative assessments and for annotation and mark up using their ‘red pen’ annotation tool. These informal tools will be adapted and developed to also include provision for the import and export of InteropAbility compliant data.

Issues

73. Two main issues we face with our frameworks:

Exam specifications include provision for groups of units, which are themselves layered groups of criteria and objectives, to be combined according to qualification specific rules of combination. We believe that the existing specification can accommodate such rules by use of ‘required by’ and ‘optional’ relationship tags. Further research is required.


15

Exam specifications can include complex mark schemes, which can operate at one or more layer within a framework. The scaleItem component of the draft specification may go some way to satisfying our requirement, but the purpose for which scaleItem is intended is different to the one we intend. TAG believes that there will be a requirement from us for a more sophisticated scoring component.

Future development

74. TAG’s assessment management system is designed to facilitate the development and assessment of formative and summative assessments through their work with schools, colleges and accreditation organisations across the world. In the next iteration of the MAPS system, all assessment tasks, formal and informal, will include InteropAbility compliant import and export functionality. This will allow teachers and assessment managers to create and export InteropAbility compliant assessments.

75. TAG also maintains a Red Pen annotation and mark-up tool. This tool is designed to facilitate the precise linkage of assessment evidence to individual criteria. This system will be adapted to include native acceptance of InteropAbility compliant assessment schemes.

University of Newcastle


76. Newcastle University hopes to use the InteropAbility specification to provide a mechanism to connect learning objects easily with professional and educational standards through the Dynamic Learning Maps system (DLM).

77. An exporter has been added to DLM to allow curriculum maps to be exported in the InteropAbility specification. The Newcastle Graduate Skills Framework has been exported from DLM and imported successfully into the PebblePad profile builder.

78. A simple importer has also been developed for DLM. This is work in progress, although it will be made available through the online demonstrator of DLM (at https://learning-maps.ncl.ac.uk) when completed. It is hoped that this will form part of a mechanism to allow learners to connect their own map to published standards.

Framework availability

79. Newcastle University has provided a download of the Newcastle Graduate Skills Framework in the InteropAbility framework, but the DLM exporter will allow any collection of competencies and skills recorded within DLM to be downloaded. This includes frameworks for numerous elements of the MBBS programme at Newcastle including a hierarchical representation of “diseases and conditions” and “medical specialties”.

Issues

80. The importer currently has a number of limitations.

a. It assumes that the imported XML file is no more than four levels deep.

b. It currently only supports subAbility relationships. DLM supports a multitude of relationship types, so we will be making extra relationship types available at a later date after the end of this project.

c. DLM has no support for scaleItems, so these were ignored.

d. There is no natural place for the identifier to be recorded in DLM. We are currently storing this as Meta Data, but when exporting from DLM, the original identifier is lost and replaced with a new DLM-specific identifier. We would recommend that identifiers should be URIs.

e. Some exports that we tried to import into DLM failed due to unicode errors. This is a limitation of our importer, and we are working on correcting this.


16

Future development

81. The University intends to complete the initial work with DLM to enable the importer to work with non-ASCII characters, to support additional relationship types and to support additional layers of complexity.

University of Nottingham


82. Within the University, there are ongoing requirements to contextualise relevant Continuing Professional Development (CPD) courses for postgraduates according to their particular skills need. The Researcher Development Framework (RDF)12 is used in many academic Schools alongside custom skills frameworks, and categorising appropriate CPD courses according to the RDF is desirable in terms of joining and streamlining practice around postgraduate professional development requirements. The University developed an InteropAbility RDF web service and an XCRI-CAP web service which also included references to points within the RDF. This draws together data about CPD and competence making it available for postgraduate Researchers systems currently under development at Nottingham. This work was undertaken alongside the CIePD’s SAMSON-Extension project.

83. In terms of this project, changes within the CPD XCRI-CAP feed were included to reference the RDF. Further discussion is required as to exactly how XCRI-CAP should manage, present or use competence frameworks. Nottingham’s prototyping work centred on reviewing the following data flows in Figure 1, explained in the following figures and bullet points:

Figure 2: illustrates the how the proposed new systems would interact

12 http://www.vitae.ac.uk/policy-practice/234301/Researcher-Development-Framework.html


17

Figure 3: Demonstrator for competence inclusion for CPD

RDF competences were published in InteropAbility format in a web service. An input screen demonstrator illustrates how staff would attach the RDF data to

courses in the University’s CPD system that holds short courses, including postgraduate specific professional development. (see Figure 3).

The XCRI-CAP courses information web service exposes CPD for use by other systems, namely PRAM (the JISC-funded project to develop a postgraduate administration module).

XCRI-CAP would be extended to include the InteropAbility structure; this can be carried out initially through extending the hasPart element in XCRI-CAP to include a simple identifier reference (for example a URI) or the full ability details.

84. Sample information in the PRAM system presented to the student might be as given in Figure 4.


18

Figure 4: Integrated RDF competence framework information and course advertising information

Future development

85. The CIePD is keen to incorporate use of the standard into University developments, in particular to describe skills relating to employability, and connecting these with professional competences and curriculum mappings. The CIePD’s JISC-funded SHED project (Sharing HE Data) will use the new standard to expose data from institutional repositories to be reused to develop new student, employer and institutional relationships. The team is also in negotiation with EU partners to establish how competence standards could improve competence discovery across borders.

Social Conversation (X1SC9) Duration: 9 Day(s) Apply to: [email protected] Aims and objectives

This module aims to respond to the needs of the group: To increase confidence and fluency when communicating in various social

situations and in conversations To give you plenty of opportunity to discuss topics relevant to most, if not all,

students in your group To raise awareness of the intended meaning of certain phrases used by

speakers in informal conversation To discuss issues of politeness and appropriacy in conversation, depending

on who you are speaking to and what situation you are in Relevant Researcher Development Framework competencies:

Communication methods (D-2-1) Phase 1 Constructs coherent arguments and articulates ideas clearly to a range of

audiences, formally and informally, through a variety of techniques. Actively engages in knowledge exchange and debate with colleagues,

sometimes between disciplines/research areas. Appreciates the skills of rhetoric.

Phase 2 Presents work confidently. Able to persuade others, asking timely and appropriate questions. Can communicate research effectively to a diverse and non-specialist

audience. Recognises the value of ideas from outside academia and incorporates them

where appropriate. Actively engages in inter-disciplinary knowledge exchange.

Phase 3 Eloquently makes the complex accessible. Demonstrates incisive interrogative and interview techniques. Actively engages in knowledge exchange with the public, business, industry,

the professions and other users of research. Phase 4 / Phase 5

Varies approach and presents research to professional peers/expert and non-expert audience in an inspirational way.

Produces finely honed argument rapidly. Process

Awareness-raising of natural spoken English, tutor input and monitoring, plenty of practice in pairs or groups.

Who should attend Any international students who would like guidance and practice in conversational English, so as to improving general communication skills.


19

Some alternative visions

86. During the project we considered some alternative models or draft specifications that explored the boundaries of our approach.

Case 1: nested abilities

87. In this case, the top level Ability holds everything, including repeats where an Ability appears several times in the structure

Ability . Relationship . . TypeOfRelationship . . Ability . . . Relationship . . . . TypeOfRelationship . . . . Ability . . . Relationship . . . . TypeOfRelationship . . . . Ability . . . Relationship . . . . TypeOfRelationship . . . . Ability . Relationship . . TypeOfRelationship . . Ability . Relationship . . TypeOfRelationship . . Ability Or of course: Ability

Case 2: nested abilities with references

88. In this case, which is a representation of the same model as Case 1, the ability sub-structures may be complete sub-abilities or just a reference (and no detail) to an Ability held elsewhere. This is very close to our final InteropAbility model.

Ability .Relationship ..TypeOfRelationship ..Ability .Relationship ..TypeOfRelationship ..Ability .Relationship ..TypeOfRelationship ..AbilityRef (1234) Ability .AbilityID (1234)

Case 3:

89. In this case, both the structure and the Ability have separate IDs, so can be separately referenced.

Ability .AbilityRef .Structure ..StructureID ..Relationship ...TypeOfRelationship ...AbilityRef


20

..Relationship

...TypeOfRelationship

...AbilityRef

..Relationship


...AbilityRef

..Relationship


...AbilityRef Ability .AbilityRef .Structure ..StructureID ..Relationship ...TypeOfRelationship ...AbilityRef ..Relationship ...TypeOfRelationship ...AbilityRef ..Relationship ...TypeOfRelationship ...AbilityRef ..Relationship ...TypeOfRelationship ...AbilityRef

Case 4: Separating the structure and the ability

90. Somewhat similar to the Medbiquitous approach, this model was considered:

AbilityID (or could be called Framework) .AbilityID - RelationshipTypeID - AbilityID (related competence) .AbilityID - RelationshipTypeID - AbilityID (related competence) .AbilityID - RelationshipTypeID - AbilityID (related competence) .AbilityID - RelationshipTypeID - AbilityID (related competence) Full Ability Record (including AbilityID) separately, referenced from the framework.

91. Our view was that there was no advantage in referencing the ability record separately from the framework, because the ability record contents and its structural relationships were integral to the ability. In addition it is simpler technically to refer to one identifier rather than two.

Case 5: An InteropAbility Wrapper

92. In this case, the framework encloses a top level ability, thereby acting as a simple container for the abilities. This has the advantage that the container can be separately described. It has the disadvantage that the InteropAbility entity is a different type of entity from an ability entity, requiring different and additional processing, and that the substantive information to be processed is contained within the top level ability and its relationships. There is little practical difference in terms of the model between this case and the final draft InteropAbility model, while the latter is simpler.

InteropAbility .Ability . . Relationship . . . TypeOfRelationship . . . Ability . . . . Relationship . . . . . TypeOfRelationship . . . . . Ability . . . . Relationship . . . . . TypeOfRelationship . . . . . Ability


21

. . . . Relationship

. . . . . TypeOfRelationship

. . . . . Ability

. . Relationship

. . . TypeOfRelationship

. . . Ability

. . Relationship

. . . TypeOfRelationship

. . . Ability

Outputs 93. Project outputs are on the project website at http://interopAbility.org. These include:

An introduction to the InteropAbility Project Design Goals and Requirements Draft Information Model Draft InteropAbility Specification Links to all project documents including:

o The straw man spreadsheet used in discussions o A draft XML schema for the specification o A draft instance file giving a fictional example of an InteropAbility

ability o A draft XML instance file for an NOS Plumbing Unit o A draft XML instance file for the RDF

A page of InteropAbility resources on the web.

Lessons learned 94. We were conscious from the time of the tender that the funding allocation from JISC for

the expected deliverables was small, so that each partner had to contribute significant extra resource. In a time of constraints on all resources, this proved difficult to manage, and the success of the project depended on the commitment of individuals, who very often were adding the InteropAbility work to a full-time workload.

95. Our use of an XML schema rather than, for example an RDF approach, was derived from experience with this technology, and a desire to re-use material in existing schemas, rather than any particular efficacy for the problem to hand. The partners recognised that the technology adopted at this stage would not preclude use of alternative technologies in future. Additional skill sets and more time might permit a more carefully considered choice of tools in future similar projects.

96. If there had been more time and resource available, we would have found it useful to hold an additional workshop to include stakeholders from outside the project team. This might have given us useful additional perspectives on the design and tested the approach against other potentially competing views.

Conclusions and recommendations

Conclusions

Merits of the InteropAbility approach

97. The project team has found that the InteropAbility approach is conceptually and structurally simple. With only one major core component – the ability entity – upon which all the other components are built, it is readily understandable and useable. Its ease of use has been demonstrated both by the comparatively simple mapping of existing diverse competence structures into the new format, and by the relative ease with which partners have been able to import and export the constructed data.

98. In line with its design goals, the specification has re-used other standards, including Dublin Core, ISO and W3C elements, as well as part of the existing MedBiquitous


22

Consortium competency object13. It is a simple and lightweight design that is grounded on practicality and immediate benefits, based on the requirements of the partner organisations representing the needs of all organisations operating in this domain.

99. The approach taken to the specification development was both iterative and collaborative with otherwise competing private sector partners coming together to realise a greater overall potential for their combined markets; management structure was flat and project management light. This was conducive to highly productive work shop meetings and rapid prototyping. APS then produced an early straw man which was used as a highly effective base line for development and further discussion.

Demonstrations of successful and practical usage

100. The project has demonstrated a wide range of usage in different contexts (see above), ranging from professional competency maps in healthcare, HR, teaching and management, through sharing of profiles and user-created templates, qualification specification and ‘on-the-fly’ assessment schemes, to academic usage for re-use of graduate skills frameworks from one system into another, and to the integration of competences into curriculum discovery systems.

101. The project has attempted to support three main use cases:

Publishing electronic documents Use within learner based tools for annotation and assessments Browsing and discovery for reflection.

102. The first two of these use cases are well covered by work to date, and project outputs have demonstrated that the InteropAbility model serves them well. The final case requires more development work, more experimentation and more testing. It may be one of the most useful areas in the long term.

103. The project has made available some of the partners’ tools and demonstrators to illustrate the usability of the InteropAbility specification. These are available from the project website.

104. Dissemination activities are planned, in conjunction with partners’ own participation in relevant conferences and exhibitions. For example a joint session is to be delivered on Monday 11 July at Epic ’11.

Proven simplicity

105. The draft specification has proven to be easy to work with, easy to read and as a consequence easy to implement. Each of these considerations is essential to the success of the specification. Each partner has been able to implement quickly in their systems, and imports have been shown to maintain data integrity and without loss.

106. Nothing has better illustrated the power and simplicity of our approach than the ease with which partners have been able to implement the draft specification, in some cases operationally, in a short space of time. Despite the fact that at the beginning of the project there was a recognition amongst partners that the implementation of an importer was likely to be, within the constraints of the budget, unrealistic, most partners have now either developed or are in the process of developing import functions having already completed their export functions.

107. The real power of the InteropAbility specification is in the ability to network frameworks. For that power to be realised, it was absolutely vital that we first show that the specification will render standalone frameworks. This project has demonstrated that ability. The next stage is to begin to explore the value of machine readable networked frameworks.

Exemplars published and usable now

108. Implementations from partners will ensure that a significant number of frameworks in InteropAbility format are readily available for use by the community and within partners’ products and services. These include import and export demonstrators in PebblePad, TAG systems, University of Newcastle’s Dynamic Learning Maps system and an

13 These are detailed in the online resources.


23

exporter from University of Nottingham’s DANTE and RDF implementations. InteropAbility frameworks available include approximately 15 competency frameworks in PebblePad and all templates in PP+, Graduate Skills Framework from Newcastle University, and the Researcher Development Framework from the University of Nottingham (published currently on the APS website). A full list is published on the project website.

Relationship to other initiatives

109. The consortium has throughout the project been careful to consider the position of related projects, including the approach taken by MedBiquitous. Whilst the consortium recognises that the draft specification that has been produced has some differences with the approach taken by the draft MedBiquitous specification, the sense is that formally mapping between the draft standards is straightforward and that scripting the conversion between standards would be almost trivial and result in no loss of information.

110. In the next stages of the project, having established that our approach works well for a wide range of institutional and industry partners in a wide range of occupational contexts, engaging in face-to-face discussion with similar work such as that of MedBiquitous would make considerable sense; it is unfortunate that this was outside of the existing project’s scope and budget. Part of this engagement would also include exemplification of the mapping between the two drafts and also illustration of the ease with which translation between the specifications can be scripted.

Recommendations

Governance

111. The InteropAbility Project is a small one in relation to money, time and effort. It has necessarily focused on the development of the primary deliverable – the draft specification – and has not had the capacity to address the wider concerns around the process and management of the future development of the specification. Broader adoption of the specification is likely to depend on traditional concerns of standardisation: it must have proven utility, a range of adopters and have a trajectory towards becoming a de facto industry standard. As usage moves along this trajectory, a more formal governance model becomes necessary, so that organisations can have confidence that it is a sustainable part of the infrastructure, and that users can have a formal influence on maintenance and development.

112. We recommend that JISC and the partners in the consortium develop proposals for an appropriate governance model for the InteropAbility specification. Consideration should be given to whether this should be alongside or separate from other specifications in the domain, such as Leap2A. One possibility is that the existing wiki under independent governance is used as a mechanism for recording and referencing competence and assessment frameworks around the world.

Operational trialling

113. This project has concentrated on development of an information model and draft specification. Testing and prototyping has been carried out in order to prove the idea of the InteropAbility approach. Partners are committed to inclusion of the draft specification in future developments. We recommend that JISC considers funding some operational trials, so that the specification can be developed further towards formal standardisation and so that operational implementation lessons can be captured and disseminated to other organisations.

114. Discussion in the workshops has suggested that reciprocal links of abilities between frameworks could or should be used as a mechanism for verifying or confirming relationships between abilities. For example, if a system declares that a referenced ability exactly matches one of its own abilities, confirmation of that exact match from the other end of the relationship gives greater confidence for successful re-use.


24

Version control

115. Electronic publishing and re-use of competences and competence frameworks raises the key issue of version control. The project has touched upon some of the key questions here, specifically around whether structural changes necessitate new versions, and the necessity of uniquely identifying specific versions of abilities when re-using them in a fresh context. We recommend that specific additional work be commissioned to continue these investigations, as this issue is likely to impact significantly on the development of the specification.

Discovery

116. In tandem with other similar initiatives, such as XCRI-CAP, the project team recognises that there will be a need for individuals, systems and services, and organisations to be able to discover the locations of InteropAbility frameworks. There may be some simple methods, such as ‘http://www.myUniversity.ac.uk/InteropAbility/...’; however, we would like to engage with other JISC or sector wide initiatives, such as the Linking You Toolkit14 project and any proposed XCRI-CAP feed register, or other sector wide initiatives, so that a good solution can be adopted.

Vocabularies

117. The project has produced some draft vocabularies, particularly for relationships. However, more work in communities of practice is needed to develop vocabularies for category and relationships. For the latter there remains the question whether SKOS-type relationships will be generally acceptable in our community of practice, or whether our vocabularies could be simply mapped to them.

Extensibility

118. The InteropAbility specification permits the use of a common core of elements, plus additional elements for specific communities of practice. Many of its elements are optional, permitting a lightweight footprint for data exchange. For example the resource entity was added into the specification at a fairly late stage, in response to an identified need from Pebble Learning and MKM for a means of referring to linked materials of use to learners. We believe that more work on the extensibility aspects of the draft specification would greatly enhance its usefulness and therefore uptake by more organisations.

Dissemination and community portal

119. The draft specification has deliberately allowed provision for the connection of ability framework to ability framework. This could be used at an organisational level to configure complex frameworks of individual units or even at a national level to maintain massively complex frameworks of frameworks. For such work to be undertaken there is a need for a community of practice to evolve around the initial work of converting existing units into compliant exports, into a bigger picture model that explores the idea of framework discovery and the work towards the interoperability of the frameworks themselves. It is important that a forum for this work is provided, if the true potential of InteropAbility is to be realised.

120. This recommendation parallels a similar one from the XCRI-CAP Assembly in early June and represents a similar stage of development for each initiative; albeit that InteropAbility has reached this stage more quickly than XCRI-CAP. Both initiatives now have a high level of technical development and significant levels of piloting and practical work on implementations. The next stage is to convert them from technical artefacts into workaday methods that become the accepted norm for connecting systems in their domains. A useful illustration of this idea is the move from the technical IEEE 802.11 standard, only of interest to technicians, to the more readily understood ‘wi-fi’ terminology. While no-one can rally round ‘IEEE 802.11’, the term ‘wi-fi’ is more widely appreciated.

14 http://lncn.eu/toolkit


25

Appendix A: Evaluation reports

Our evaluator, Sandra Winfield from the University of Nottingham, carried out two evaluation exercises, at Workshop 2 and Workshop 3. These reports were circulated to the project team and have impacted not only on the later stages of the project but also on how partners will take on future work to make progress with project outcomes.

Workshop 2 Evaluation comments

An identified critical success factor is active engagement from each partner in workshops. So far this has been achieved, with all partners being represented at both workshops. The actual attendees have not been the same in some cases, however: while this might lead to issues of continuity, the outcome has been to broaden the input to discussion as new points of view become available.

Workshop participants engaged actively with emerging outputs. The agenda was to flesh out the ‘straw man’ specification, making outcomes more concrete (aiming for a ‘clay man’). Modifications were made to the draft, removing some sections and making others optional, and details were added to a number of entries. The methodology used has proved useful: the practical exercise of mapping various partner frameworks against the draft has both helped to validate the draft and to develop the methodology. It should be possible to validate the draft further by introducing further frameworks iteratively and repeating the process.

The diagrammatic and textual approaches seem now to be agreed on.

The comparison with the MedBiquitous framework model is a useful exercise: the specification has to be justifiable in the wider environment and the advantages capitalised on.

Next steps have been agreed: good progress is being made towards a complete and testable specification. Further involvement of external stakeholders is now appropriate.

Workshop 3 Evaluation comments

This was the third and final workshop for the project team. Workshops have involved project partners and representatives from JISC and CETIS only; however a number of individuals have been involved and discussions have represented a number of points of view. The project now needs to involve and engage a wider set of stakeholders through dissemination activity and consultation on project outputs, in particular the prototype specification. While the project plan makes clear that it is not an activity included in the funded work, there is clear indication that this would be supported by any demonstration activity partners are able to establish showing work of the prototype in practice and its potential to support interoperability.

The critical success factor of engagement from all partners has continued: the meeting included representation from all partners except one, and there was active discussion arising from all partners having hands on experience of attempting to apply the draft prototype standard to selected competence frameworks used with their systems.

The goals of the workshop goals were clearly stated as:

Synthesis and reporting Pull together testing and prototyping Finalise and agree the information model with specification & schema Demonstrate how we can move data from one system to another Next steps

There is now general agreement between partners about the structure and approach of the draft specification, which has been tested, refined and validated through application to real competence frameworks, including a sample from the National Occupational Standards for plumbing. (It would be useful to apply it to further samples from the NOS, as the structure and level of detail varies from occupation to occupation.) This work now needs to be extended and the prototype tested by a select but wider set of stakeholders than the immediate project team.


26

A useful and important next step has been the agreement of partners to explore how they might import and export between each others’ systems; this will offer a more robust test of the prototype, showing how it retains integrity during interoperability, which is a vital rationale for development of the specification. The development of a web service by Nottingham is also a valuable indication of how the specification might be used in a wider context.

Awareness raising is now crucial if the project is to have lasting impact. Plans are being made for dissemination and wider consultation activity: the project now needs to ensure that the wiki is kept up to date and promoted in the community, and that they develop a set of discrete materials that others can explore, worked out via the original use cases from the plan.

The issues of sustainability and governance, though discussed between partners, also still need to be resolved in consultation with JISC. This should be addressed through a set of recommendations in the final report.


27

Appendix B: Example of PRAM course (University of Nottingham) in XCRI-CAP format, extended to include Researcher Development Framework information <course recdatetime="2011-06-23T13:15:47+00:00"> <mlo:hasPart>rdf:D-2-1</mlo:hasPart> <relationship> <typeOfRelationship>isSubAbilityOf</typeOfRelationship> <abilityRef>D-2</abilityRef> </relationship> <scale> <scaleItem> <value>1</value> <term>Phase 1</term> </scaleItem> <scaleItem> <value>2</value> <term>Phase 2</term> </scaleItem> <scaleItem> <value>3</value> <term>Phase 3</term> </scaleItem> <scaleItem> <value>4</value> <term>Phase 4</term> </scaleItem> <scaleItem> <value>5</value> <term>Phase 5</term> </scaleItem> </scale> </ability> <identifier>http://training.nottingham.ac.uk/cbs-notts/Guests/GuestCourse.aspx?CourseRef=X1SC9</identifier> <title>Social Conversation</title> <subject>Academic Language & Writing Skills</subject> <description xsi:type="terms:topic"> <div xmlns="http://www.w3.org/1999/xhtml"> <h1>Module description</h1> <h2>Aims and Objectives</h2> <p>This module aims to respond to the needs of the group:</p> <ul> <li>To increase confidence and fluency when communicating in various social situations and in conversations</li> <li>To give you plenty of opportunity to discuss topics relevant to most, if not all, students in your group</li> <li>To raise awareness of the intended meaning of certain phrases used by speakers in informal conversation</li> <li>To discuss issues of politeness and appropriacy in conversation, depending on who you are speaking to and what situation you are in</li> </ul> <h2>Process</h2> <p>Awareness-raising of natural spoken English, tutor input and monitoring, plenty of practice in pairs or groups.</p>


28

<h2>Who should attend</h2> <p>Any international students who would like guidance and practice in conversational English, so as to improving general communication skills.</p> </div> </description> <url>http://training.nottingham.ac.uk/cbs-notts/Guests/GuestCourse.aspx?CourseRef=X1SC9</url> <presentation recdatetime="2011-06-23T13:15:47+00:00"> <identifier>X1SC9</identifier> <duration>9 Days</duration> <studyMode xsi:type="terms:studyModeType">Part Time</studyMode> <applyTo>[email protected]</applyTo> <enquireTo>Staff Training: 0115 951 5151</enquireTo> </presentation> </course> Separate InteropAbility data pulled in from web service: <interopAbility> <dcterms:identifier>RDF</dcterms:identifier> <dcterms:title>Researcher Development Framework</dcterms:title> <ability> <dcterms:identifier>D-2-1</dcterms:identifier> <dcterms:title>Communication methods</dcterms:title> <description><div> <div><h1>Phase 1</h1> <p>Constructs coherent arguments and articulates ideas clearly to a range of audiences, formally and informally, through a variety of techniques.</p><p>Actively engages in knowledge exchange and debate with colleagues, sometimes between disciplines/research areas.</p><p>Appreciates the skills of rhetoric.</p></div> <div><h1>Phase 2</h1> <p>Presents work confidently.</p> <p>Able to persuade others, asking timely and appropriate questions.</p> <p>Can communicate research effectively to a diverse and non-specialist audience.</p> <p>Recognises the value of ideas from outside academia and incorporates them where appropriate.</p> <p>Actively engages in inter-disciplinary knowledge exchange.</p></div> <div><h1>Phase 3</h1> <p>Eloquently makes the complex accessible.</p> <p>Demonstrates incisive interrogative and interview techniques.</p> <p>Actively engages in knowledge exchange with the public, business, industry, the professions and other users of research.</p></div> <div><h1>Phase 4 / Phase 5</h1>


29

<p>Varies approach and presents research to professional peers/expert and non-expert audience in an inspirational way.</p> <p>Produces finely honed argument rapidly.</p></div> </div></description> </ability> </InteropAbility>

InteropAbility Project Report Final 1.2 · Background and introduction 1. In December 2010 JISC...

Documents

Transcript of InteropAbility Project Report Final 1.2 · Background and introduction 1. In December 2010 JISC...