Other cross-structure relationships

(9th in my logic of competence series)

My previous post covered how to do common competence features in different structures, typically where the structures share context. But what about when the two structures are from quite different starting points? Equivalences are harder to identify, but it may be useful to document other relationships.

My earlier post on the basic structures taken separately contrasted the UK LANTRA NOS’s with the QAA‘s Subject benchmark statement in the area. The way in which these are put together is quite different, and the language used is far from the same.

But there may be a good case for relating these two. What would happen if someone who has a qualification based on NOSs wanted to give evidence that they have attained Subject Benchmarks? Or, more likely, what if someone who has a vocational qualification in, say, agriculture wants to select modules from a degree course in agriculture, where the intended learning outcomes of the university’s degree course refer to the appropriate Subject Benchmark Statement? Even if there are no equivalences to note (as discussed in the previous post) we may see other useful relationships, such as when something in one structure is clearly part of something else in another structure, or where they are not equivalent, but they are meaningfully related. Let’s see what we can find for the (not atypical) examples we have been looking at.

Starting hopefully on familiar ground, let’s look at the generic skills related to the LANTRA unit CU5 that I’ve mentioned before. Element CU5.1, or unit CU5 in the 2010 Veterinary NOSs, is called “Maintain and develop personal performance”, and this seems related to the Benchmark’s “Self-management and professional development skills”. They appear not to be equivalent, so we aren’t justified in creating a skos:exactMatch or skos:closeMatch relationship between those two structures, but we could perhaps use skos:relatedMatch (another SKOS Mapping Property) to indicate that there is a meaningful relationship, even if not precisely specified. This might then be a helpful pointer to people about where to start looking for similar skill definitions, when comparing the two structures. The Benchmark seems to be generally wider than the NOS unit, and perhaps this would be expected, given that graduate level skills in agriculture should cover something that vocational skills do not. Here, “moral and ethical issues” and “professional codes of conduct” are not covered in the NOSs. Perhaps the closest correspondence can be seen with the Benchmark’s “targets for personal, career and academic development”, prefaced at “threshold” level by “identify…”, “typical” level by “identify and work towards…” and “excellent” level by “identify and work towards ambitious…”. In the NOS, the individual must be able to: “agree personal performance targets with the appropriate person”; “agree your development needs and methods of meeting these needs with the appropriate person”; “develop your personal performance according to your agreed targets, development needs and organisational requirements”; and “review personal performance with the appropriate person at suitable intervals”. They must also know and understand (among other things) “how to determine and agree development needs and personal targets”. Personally, I’m not sure whether anything deserves a skos:closeMatch property — probably what we would need to do would be to get the relevant people together to discuss the kinds of behaviour covered, and see if they actually agree or not on whether there was any practical equivalence worthy of a skos:closeMatch.

There is also a definite relationship between the Benchmark’s “Interpersonal and teamwork skills” and the NOS’s “Establish and maintain working relationships with others”. Again, it is difficult to identify any very clear relationships between the component parts of these, but despite this lack of correspondence at fine granularity, it seems to me that the five ability points from the NOS are more than covered by the five points appearing at the “typical” level of the Benchmark. There are two other SKOS Mapping Properties that might help us here: skos:broadMatch and skos:narrowMatch. These correspond to skos:broader and skos:narrower, but applied across different structures, rather than within one structure. Thus we could potentially represent that LANTRA CU5A (2010) has a “skos:broadMatch” in the Benchmark’s Interpersonal and teamwork skills, “typical” level. Conversely, that “typical” Benchmark component has a “skos:narrowMatch” in LANTRA’s CU5A.

On the subject-specific end, again there are plenty of areas where you can see some connection, but hard to see very clear distinct relationships. As you might expect, there is a tendency for the NOSs to deal with specific skills, while the Benchmark deals in more general knowledge and understanding. The horticultural PH16 NOS unit is titled “Respond to legislation affecting consumer rights”, while the Benchmark has various “subject-specific knowledge and understanding” to do with “social, economic, legal and technological principles underlying the business management of farm or horticultural enterprises”. Probably, people meeting this part of the Benchmark standard at a good enough level have skills that include that unit of the NOS, so we could in theory note a skos:broadMatch relationship between the NOS unit and that part of the Benchmark. But we could only do that (for any area) if we had URI identifiers available to mark the relevant sections unambiguously, and at present there are few if any competence structures where URIs have been officially assigned to the parts of the structure.

It seems unlikely that an agriculture graduate would be wanting accreditation of a LANTRA NOS unit, but if someone did, supporting systems could potentially make use of these relationships represented as SKOS Mapping Properties. More likely, someone who has covered the LANTRA NOS would be able to save a lot of time in putting together a shortened agriculture degree programme if all the skos:broadMatch relationships were documented, as it would be relatively easy to design a tool that allows efficient comparison of the relevant documentation, as a support to deciding whether a particular module at degree level needs to be taken, or not. This seems likely to be a similar process to Accreditation of Prior Learning (APL) in which the university accredits previous attainment in terms of their degree programme. It could also be adapted to APEL (E = “Experiential”) if the individual brought along a portfolio of evidence for attaining relevant NOSs. These processes are important in the likely future world where tailoring of degree courses becomes more common.

It looks like I have finished the coverage of the essential logical features of competence structures that I believe could usefully be incorporated in an interoperability specification. To repeat a point I have inserted in the introduction to this series, I would be delighted to discuss any of these posts one-to-one with interested people. It remains to bring all these points together in a way that is easier to follow, through the judicious use of diagrams, to discuss other emergent issues, and to talk about how we could work towards the practical implementation of such competence structures. The first diagram offered is a concept map, together with definitions.

Representing common structures

(8th in my logic of competence series)

In the last two posts, I’ve set out some logic for simple competence structures and for more complex cases. But we still need to consider how to link across different structures, because only then will the structures start to become really useful.

If you look at various related UK National Occupational Standards (NOSs), you will notice that typically, each published document, containing a collection of units, has some units specific to that collection and some shared in common with other collections. Thus, LANTRA’s Production Horticulture NOSs (October 2008) include 17 common units that are shared between different LANTRA NOSs, and Agricultural Crop Production NOSs (May 2007) include 18 of these units. Ten of them appear in both sets. Now if, for instance, you happen to have studied Production Horticulture and you wanted to move over to Agricultural Crop Production, it would be useful to be able to identify the common ground so that you didn’t have to waste your time studying things you know already. And, if you want to claim competence in both agriculture and horticulture, it would be useful to be able to use the same evidence for common requirements.

How can what is in common between two such competence structures be clearly identified? There are currently common codes (CU2, CU5, etc.) that identify the common units; and units imported from other Sector Skills Councils (as frequently happens) are identified by their unit code from the originating NOSs. However, there are no guarantees. And if you look hard, you sometimes find discrepancies. CU5, for example, “Develop personal performance and maintain working relationships”, is divided into two elements, “Maintain and develop personal performance” and “Establish and maintain working relationships with others”. In both sets, “others” are defined as

  1. colleagues
  2. supervisors and managers
  3. persons external to the team, department or organisation
  4. people for whom English is not their first language.

But when the unit CU5 appeared in Veterinary Nursing NOSs in 2006, non-native English speakers were not explicitly specified. Do we have to regard the units are slightly different? We can imagine what has happened — presumably someone has recognised an omission, and put it what was missing. But what if that has been reflected in the training delivered? Would it mean that people trained in 2006 would not have been introduced to issues with non-native speakers? And does that mean that they really should be given some extra training? And later the plot thickens… LANTRA’s “Veterinary nursing and auxiliary services” NOSs from July 2010 has CU5, “Maintain and develop personal performance” and CU5A, “Establish and maintain working relationships with others”. This seems to follow a pattern of development in which the NOS units are simplified and separated. The (same) different kinds of “others” are now just included in the overview paragraph at the beginning of CU5A.

I hope it’s worth going through this exercise in possible confusion to underline the need for links across structures. Ideally, an occupational standard should be able to include a unit from elsewhere by referring to it, not by copying it; and there would need to be clear versions with clearly marked changes. But if people insist on copying (as they currently often do), at least there could be very clear indications given about when something is intended to be exactly the same, and when it is pretty close even though not exactly the same.

Back in the simple competence structures post, I introduced the SKOS relationships “broader” and “narrower”. There are other SKOS relationships that seem perfectly suited for this job of relating across different competence structures. These are the SKOS Mapping Properties. It would seem natural to take skos:exactMatch to mean that this competence definition I have here is intended to be exactly the same as that one over there, and skos:closeMatch would serve well for “pretty much the same”, or “practically the same”. If these relationships were properly noted, there could be ICT support for the kinds of tasks mentioned above — e.g. working out what counted as evidence of what competence, and what you still needed to cover in a new course that you hadn’t covered in an old course, or gained from experience.

And if all parts of competence structures were given globally unique IDs, ideally in the form of URIs, then this same process could apply at any granularity. It would be easy to make it clear even to machines that this NOS unit was the same as that one, right down to the fine granularity of a particular knowledge or ability item being the same as one in a different unit. An electronic list of competence concepts would have alongside it an electronic list of relationships — a kind of “map” — that could show both the internal “skos:broader” and “skos:narrower” relations, and the external “skos:exactMatch” and “skos:closeMatch” equivalencies.

This gives us a reasonable basis for reuse of parts, at any level, of different structures, but we haven’t yet considered comparison of competence structures where there aren’t any direct equivalence mappings.

CPD-Eng – review of a JISC project in progress

I was asked to look into the CPD-Eng project by the JISC programme managers, specifically in conjunction with the JISC “Benefits Realisation” work, because this project in particular has a lot to do with portfolio technology and interoperability, and then with skills and competences in professional development.

CPD-Eng is a JISC-funded project, to quote from the JISC project page, “to integrate systems that support personalised IPD/CPD, applicable to professional frameworks.” The lead institution is the University of Hull, and much of the documentation can be found through their own project page.

The project start date was April 2009. At that date, the tender documentation spelled out the aspirations for the project. The main image that emerges from the tender documentation is not of a new e-portfolio system as such, but of an approach to integrating evidence that may reside on different systems, all of which has relevance to an individual’s CPD. “CPD-Eng will provide the innovative, personalised infrastructure that will support the work-based learner through a new suite of flexible pathways…”

The original plan was to deploy Sun’s Identity Management software, perhaps aiming towards Shibboleth in the longer term. These were overtaken by various events. Consultations with various people related to JISC lowered the perceived value of Shibboleth, and in any case there needed to be a more open approach to accommodate the wider potential usage of the tools.

One of the shaping factors was the requirement to integrate the Hull institutional VLE (“eBridge”), based on the SAKAI framework. Right from the outset there was explicit mention also of integrating e-portfolio systems that have adopted Leap2A. Clearly, one of the main areas of future evidence of the success of a project that claims to be about integrating systems will be the actual extent of integration carried out. In the project plan, WP7 states that the most important integration is between eBridge and other partners’ VLEs. The nature of the integration, however, was not specified at the outset, but remained to be filled in through earlier work in the project itself. A theme that does continue throughout the tender is about the ability of learners to control access to information that may be stored in different places.

The baseline report (version 0.9 of August 2009) spells out more graphically where the project started from. Perhaps the core point at the centre of the vision is the statement: “A portal system has been established alongside an Identity Management (IDM) system that allows self-service management of the learner’s identity. CPD-Eng will develop a robust and scalable approach to interoperability, access and identity management that is both easy to use and seamless, allowing the learner to control their personal e-portfolio-type technologies and share the content within them with whom they choose.” Compared to this, the rest of the baseline report is interesting background.

After the baseline report the project took stock of the situation. Some other portfolio products were “not very engineering”. TAS3 was not seen as very user-friendly. Academics still wanted the software to sit in SAKAI. Unfortunately, the lead programmer resigned to take up employment elsewhere, and the project was left without a developer. After looking into advertising for a replacement, and consulting with the JISC Programme Manager, it was decided to put the software development out to tender. MyKnowledgeMap (MKM: a York-based company with a track record of producing software in the area of skills and portfolios, for users in education and various professions) was judged as the most suitable partner, though they lacked experience of SAKAI. The project leads arranged for MKM employees to be trained by the University’s consultant, Unicon.

This was the situation for the following progress report of 2010-03. Three software modules were being developed within SAKAI:

  • Aggregator
  • Mapper / Tagger
  • Showcaser

The Aggregator module “provides a mechanism for users to gather their artefacts and items of evidence from across multiple sources.” While it is relatively easy simply to copy information from other sources into a system like this, the point here is explicitly “not” (emphasis original) to copy, where it is possible to establish access from the original location.

Tagging is conceived of similarly to elsewhere, in terms of adding free text tags to aid categorisation by individuals. Mapping, in contrast, is designed to allow users to connect artefacts to elements of established “skills, competency and assessment frameworks”. This function is vital within CPD practice, so that users can present evidence of meeting required standards. Such frameworks are stored externally. JISC is now funding some “Competence structures for e-portfolio tools interoperability” work finishing July 2011, and CPD-Eng can play a useful role in determining the standard form in which competence structures should be communicated. MKM does have existing techniques for this, but they will be critiqued and adapted as necessary before being adopted as a consensus.

Showcasing is conceived of similarly as in many portfolio tools. Official review is supported by routine copying of showcases to uneditable areas. This works for e.g. health professionals, because they want a carefully controlled system, though others like engineers need that less, and prefer to do without the extra burden of storage. It is planned to support review without necessarily copying showcases in a later release. Access to showcases was originally only via SAKAI, but it was later recognised that limiting to SAKAI access was not ideal, particularly as many professional bodies have their own e-portfolio systems.

Working with health professionals, archeologists and others (there is also interest from schools, and a pilot with BT), it became clear that a useful system should not be tightly bound to other institutional software or to SAKAI, so what was needed was an independent identity management system.

In the Benefits Realisation plan from the summer of 2010 came a clear restatement of the core aim of the work. “At its centre is a scalable, interoperable and robust access and identity management system that integrates and control access to personal e-portfolio technologies.” But what is the relationship between the CPD-Eng work and other identity management systems? Sun’s Identity Management software had been abandoned. The European funded TAS3 work (in which the University of Nottingham is a partner) was seen as too complex for professional end users. A question which remains outstanding is to clarify the relationship of the system devised with the trials funded by JISC under the PIOP 3 programme, involving PebblePad, the University of Nottingham and Newcastle University. It would be good to see a clear exposition of these and any other relationships. All that can be said at this stage is that in the perception of the CPD-Eng project, none of the other identity management systems really worked for them.

The next piece of documentation is the progress report from September 2010. This is where the questions really start to become clearer. Included in this massive report is the complete text of the final report from “Personalised systems to support CPD within Health Care”, a mini project extending CPD-Eng concepts to health care professions. In this very interesting inner report, there is a large body of evidence about CPD practice in the health professions. This leads to a second major question. What about the whole process side of portfolio practice? CPD-Eng has very clearly focused on the rather technical side of facilitating the access management for artefacts. This is certainly useful at the stage when all the evidence has been generated, when it remains to gather together appropriate items from different places.

Much portfolio practice centrally involves reflection on evidence as well as its collection and showcasing. The phrase “collect, select, reflect…” is often used in portfolio circles. (Helen Barrett adds direction/projection and connection.) Reflection is often vital in portfolio practice, because the mere presentation of a selection of artefacts is no guarantee of a clear and coherent understanding of how and why they fit together. Because unprompted reflection is hard, institutions often support the process. It is useful to be able to build in some aspect of process into the same tools which hold the information and resources to be reflected on, and it is useful to hold the reflections themselves in a place that they can be easily connected with the things on which they are reflecting.

Increasingly, it is recognised that the peer group is another vital aspect of this reflection process. In a situation where staff time is short, or the staff seem uninvolved, possibly the best stimulus for reflection and re-evaluation of ideas is the peer group. Portfolio systems designers themselves have recognised this, by integrating social tools into the portfolio software.

It is clear that MyShowcase is not primarily designed to support reflection. (More information about MyShowcase can be found at www.my-showcase.org which has a demo and links, and through www.mkmlabs.com.) However, one of the consequences of implementing a stand-alone version is that users found an immediate need for some of the functionality that is normally provided within full-feature e-portfolio systems. In particular, users want to collect evidence together and send a link to a tutor for feedback. The link is sent to the reviewer by e-mail, who can then access the system for the purpose of leaving feedback comments. Indeed, some users feel that fully-featured e-portfolio systems are just too complex for their users’ needs, and value a simple tool because it does less, and does not explicitly support reflection by users. So this is the only extra feature implemented in MyShowcase that comes from the fuller set normal in portfolio software.

If one has a hybrid system including MyShowcase and some other portfolio tool, the portfolio functionality will therefore mainly be fulfilled in the portfolio tool, not MyShowcase. But what of the feedback that has been designed into MyShowcase for standalone use? To be useful, it would have to seen within the portfolio system. And generally, any information used in MyShowcase needs to be presented to the associated e-portfolio system for use within whatever (e.g. reflective) processes the portfolio software is used for. We don’t want the flow of information to be only one-way, or there to be solely unidirectional two-stage processes. What is needed is an effective two-way integration, so that the chosen portfolio tool can access all the information gathered through MyShowcase, the user / learner can gather further feedback and reflect, and present the outcomes of that further reflection back into the MyShowcase pool, for onward presentation.

Recent discussion has confirmed that MyShowcase is not primarily conceived of as a replacement for a full e-portfolio system, though it does act as what we might call an “evidence resource management” tool. Perhaps we can now discern an ideal answer to where this might lead, and where things ought to be heading, and the questions that still need to be answered.

If a service such as MyShowcase is to work effectively alongside e-portfolio tools, there needs to be transfer of information all ways round. In addition to this, and because it can be implemented stand-alone, there needs to be Leap2A export and import directly between MyShowcase and a user’s personal storage.

Looking at things from a user’s perspective, a portfolio tool user should be able to make use of MyShowcase functionality transparently. It should be able to be used as invisible “middleware”, allowing the front end e-portfolio system to focus on an appropriate user interface, and portfolio and PDP processes (including reflection and feedback), with MyShowcase providing the funcationality that allow the user to link to evidential resources held in a variety of places, including VLEs, HR systems, other portfolio tools, social networking services, blogs, etc., possibly including sites with sensitive information that will only be displayed to authorised users.

The MyShowcase architecture in principle could provide resource management for “thin portfolio” services, where the storage is not in the portfolio system. Is it, or could it be, adapted for this?

As part of the PIOP 3 projects, Leap2A connection between different systems was been investigated by PebblePad, Nottingham and Newcastle, and this work needs to be carefully compared with the MyShowcase architecture. What exactly are the similarities and the differences? Are they alternatives? Can they be integrated, combining any strong points from both?

In order to facilitate this two-way interaction, there really needs to be substantial compatibility between the information models in all the connected systems, so that there can be meaningful communication between the systems. This does not necessarily mean a full implementation of Leap2A in each participating system, but it does mean at least a reasonable mapping between the information managed and corresponding Leap2A structures, because Leap2A is the only well-implemented and tested model we have at this time that covers all the relevant information. If there are requirements that are not covered by Leap2A, this is a good time to raise them so that they can be incorporated into discussion with other parties interested in Leap2A, and our common future thinking.

I hope I’ve made the issues clearer here. Here are collected recommendations for taking this work forward, whether within the current CPD-Eng and Benefits Realisation work or beyond it.

  • What the portfolio community really needs is multi-way integration of portfolio information, artefacts and permissions, based around Leap2A concepts.
  • Leap2A export and import by users should be provided for standalone implementations of MyShowcase, just as with other portfolio systems that have adopted Leap2A.
  • Showcases in MyShowcase need to be exportable as Leap2A (as with PebblePad WebFolios and Mahara Views).
  • For transparent integration between different sources of information in a portfolio architecture, identity management approaches need consolidating around good workable models such as OAuth
  • The PIOP 3 work by PebblePad Nottingham and Newcastle, as well as TAS3, need to be carefully considered, to extract any lessons relevant to CPD-Eng, even if their appearance is only in the final report.
  • The opportunity provided by any planned project meeting should be fully exploited in these directions.
  • Another meeting should be planned around the wider questions of e-portfolio interoperability architecture, covering not only the technical aspects, but the requirements of practice as well, such as reflection, feedback and comments on non-public items stored elsewhere.

Advanced structures for competences

(7th in my logic of competence series)

In my previous post, I explained how SKOS relationships can be used to represent the basics of competence structures. But in one of the examples cited, the QAA Subject Benchmark Statement for honours level agriculture related studies, the aspect of level of attainment is present, and this is not easily covered by the SKOS broader and narrower relations just by themselves. Let me explain in some more detail.

In this particular Subject Benchmark, the skills, knowledge and understanding are described at three levels: “threshold”, “typical”, and “excellent”. As a first example, in one of the generic skills, (communication skills), under “threshold” one item reads “make contributions to group discussions”; under “typical” the corresponding item reads “contribute coherently to group discussions”; and under “excellent” it reads “contribute constructively to group discussions”. Or take an example from the “subject specific knowledge and understanding in agriculture and horticulture” — threshold: “demonstrate some understanding of the scientific factors affecting production”; typical: “demonstrate understanding of the scientific factors limiting production”; excellent: “demonstrate understanding of the scientific factors limiting production and their interactions”. Leaving aside difficulties in clarifying and assessing exactly what these mean, it is clear that there is a level structure, as illustrated in my earlier post. In both cases, the three descriptions are neither identical nor unrelated — higher levels encompass lower ones. (But note also that benchmark statements in different subjects have different structures.)

Can one represent these attainment levels in a tree structure? One option might be to have three benchmark statements presented separately, one each for threshold, typical and excellent. However this would miss the obvious connections between the elements within each level. A more helpful approach might be to describe the common headings with the finest reasonable granularity, and then distinguish the descriptors for different attainment levels at this granularity. This would need a slight restructuring of this statement, because finer-grained common headings are possible than the ones given. For instance, “subject specific knowledge and understanding in agriculture and horticulture” could easily be subdivided into something like these, (using words that appear in each level):

  • “science and management of sustainable production systems”
  • “social, economic, legal, scientific and technological principles underlying the business management of farm or horticultural enterprises”
  • “range of concepts, theories and methods drawn from the constituent disciplines”

At a still finer level, the descriptors mostly share many words, with just the detail differing to reflect the different levels, as exemplified above. In the example above, the common wording is “understanding of the scientific factors affecting production”. Headings could be created from common wording. Then there is still the issue of relating the three described levels into the structure as a whole. Threshold, typical, and excellent are not three components of one higher level entity, they are different levels of the same entity. These levels are one kind of variant.

Variants more generally are not always easy to see in common definitions, perhaps because part of the point of having standards is to reduce variability. For a clearer example from a broader perspective, we may consider areas not documented by occupational or educational standards. Consider skill and competence at management. The literature suggests several distinct styles of management: autocratic, democratic, laissez-faire, paternalistic, etc. It is probably obvious that to be an effective manager, one does not have to be able to manage according to all these styles. Perhaps just one may be good enough for any particular management position, though different ones may be needed in different contexts. Having chosen a management style, each will have a different range of component skills. If one wished to create a tree structure to represent management competences, what would the relationship be between a reasonable topmost node, perhaps called just “management”, and the four or more styles? It is rather similar to the issue with the levels we saw above, but at a different granularity. As another alternative example, look at the broader issue of developing competence in agriculture or horticulture. Probably no one is an expert in growing everything. Anyone wanting to be a farmer or grower will at some point need to decide what to specialise in, if not in academic study, then at least in terms of practical experience and expertise. There are clear choices, and the range of skills and competence needed for different specialisms will of course differ. Being a competent farmer does not mean being competent at growing all crops in the world. You have to choose.

The basic structures mentioned in my previous post start out with the idea of “broader” and “narrower” concepts. It is reasonable to say that management competence in general is a broader concept than competence as a democratic manager? Or can one say that graduate level competence in agriculture is a broader concept than being assessed as threshold, typical or excellent? Does it really help to say simply that horticulture is a broader concept than growing grapes?

What seems to emerge on thinking this through is that there are at least two kinds of “broader” (and equally two kinds of “narrower”) with different logic. One type is like whole-part relationships. We saw this in the National Occupational Standards units, which were composed of things that a person needs to be able to do, alongside things that the person needs to know. In principle all parts are needed to constitute the whole. If we imagine say a personal development or learning tracking system that helps you with your learning, and you were working towards the unit of competence, then the system could keep track of which ones you say you have done, and perhaps remind you to complete the remaining ones.

On the other hand, the other type of relationship (illustrated above) is “style” or “variant” rather than “part”. If we imagine a system to help with professional development, and you wanted to develop your management skill, it is at least plausible that you could be asked at the outset which style of management you would like to improve your skill in. Having chosen one (or more) the rest would be put aside. You would work towards the constituent knowledge and skills for the chosen ones, and the system would not bother you with the knowledge and skills needed for the styles you had chosen not to learn more about. Similarly, a general horticulture skill aid would have to start by getting you to select the kind of crops you wanted to grow. And for the other example, with the attainment standards of the Subject Benchmark, we can imagine selecting a topic and then being asked what level you believe you have attained on this topic, so again there is a selection process instead of simply the combination of parts.

One could indeed imagine all of these features together in a tool that helped with personal development. The system could ask you what level you believe you have attained already, and what level you are working towards, for fine grained knowledge and skills, and then reminding you to work at the identified gaps. At the same time, which fine grained areas you work at will depend on your more course-grained choices, like which styles of the competence you want to acquire, and which options you will specialise in.

It may help to compare these two kinds of relationship with ones that are very common elsewhere. UML distinguishes various relationships within class diagrams by graphical symbols, and two of the most common are called “composition” and “generalization”. Composition is very close to the kind of basic relationship in competence where component skills and knowledge are required to make up a wider competence, or that various competences are required to qualify as a certain grade of professional. On the other hand, the broad concept of management competence could be seen as a generalisation of the more specific competences in various styles of management. A word of caution, however: UML is designed specifically for use in systems analysis and design, or software engineering, so it should not be suprising if the match with representing competence is not exact.

Even though the two kinds of relationship I have been talking about are well known in many fields, SKOS does not make an explicit distinction between them. Logic seems to lead to the idea (which I have heard SKOS experts suggesting) that it is up to others to define more specific relationships than (specialisations of) SKOS’s “broader” and “narrower” to represent these two kinds of relationship. We don’t want to deprive SKOS of the right to be called “Simple”.

However we represent these two kinds of relationship, if we are going to represent them in a way which is useful for tools to help people manage their competence, their learning towards competence, and their self-assessment of competence (perhaps leading to external assessment) then it does seem entirely appropriate to represent them differently. Very simply, there are times when you need all of a set of components, and there are times when you need to choose which of a group of options you are going to choose: “and” and “or”; and both kinds of relationship are of great practical use.

Addition, 2011-06-22 On the other hand, people seem to easily mix compulsory and optional parts in the same structure. This is extremely widespread in the definition of qualifications, which are still a very important proxy for or indicator of abilities and competence. So, rather than needing necessarily to separate out the two kinds of structural relationship, we can simply be liberal about accepting whatever combinations people want to represent. If a certain ability has both necessary and optional parts, it is still very easy to understand what that means in practice, and to follow through the implications.

2011-07-04 And I give detailed argument to the reasons for optionality in post 15 in this series.

That may be a good place to stop for defining generic structure for single framework structures of skills or competence. But what I have not covered so far is relationships between different competence structures. One thing this is needed for is reuse of common elements between definitions…

Basic structures of competences

(6th in my logic of competence series)

In the earlier post on structure, I was looking for the structure of a single “definition” of “what is required”. In following that line of enquiry, I drew attention to one of the UK National Occupational Standards (NOSs), in horticulture as it happened. Other UK NOSs share a similar structure, and each one of these could be seen as setting out a kind of relationship structure between competences in that occupational area. In each case we see an overall area (in the case cited, “production horticulture”), which is broken down into units, where each unit seems to correspond roughly to an occupational role — one of a set of roles that could be distributed between employees. Then, each unit is broken down into what the person with that role has to be able to do, and what they need to know to provide a proper basis for that ability.

This is clearly a kind of tree structure, but it is not immediately obvious what kind of tree. Detailed consideration of a few examples is instructive. A first point to note is that NOS units may occur within several different occupational areas. This is particularly true of generic competences such as health and safety, but also applies to some specific units of skill and competence that just happen to play a part in several occupational areas, or several careers if you like. So, a particular unit does not necessarily have a single place on “the tree”. A second point emerges from consideration of different trees. UK NOSs have a common structure of, roughly: responsible body (usually a Sector Skills Council); occupational area; unit; skill or knowledge. But this is not always the case with structures that are not NOSs. For example, the “Tuning” work on “educational structures in Europe” includes “generic competences” that are given just as headings, from “capacity for analysis and synthesis” to “will to succeed”, and there is no attempt to break these down into smaller components.

Tuning’s specific competences have the same depth of tree structure as their generic ones, still unlike NOSs. For instance, the “business-specific competences” have items such as “identify and operate adequate software”, which looks a bit like some of the things that NOSs specify that people have to do, but also items such as “understand the principles of law and link them with business / management knowledge”, which seems to correspond more with NOS knowledge items. Some Tuning items straddle both ability and knowledge. In all Tuning cases, the tree structure is shallower than for NOSs. You may find many other such tree-structures of competences, but I doubt you will find any reliable correspondence between the kinds of thing that appear at different points on different trees. This is a natural consequence of the logical premise of this whole series: that it is the claim and the requirement that are the logical starting point. Yes, we may well see correspondence at that level of job requirement, and much common practice; but any commonality here will not extend to other levels, because people analyse claims and requirements in their own different ways. It’s not just that some trees leave out particular kinds of branch, but rather that, to go with the natural analogy, branches come in all thicknesses, with no clear dividing line between say a branch and a twig.

Even for the same subject area, there are quite different structures. As well as NOSs, the UK has what are called “subject benchmarks”, which are more for academic courses rather than purely vocational ones. The QAA‘s Subject benchmark statement for “Agriculture, horticulture, forestry, food and consumer sciences” has this structure:

  • 8 very general “abilities and skills”, such as “understand the provisional nature of information and allow for competing and alternative explanations within their subject”
  • other generic skills divided into
  • intellectual skills
  • practical skills
  • numeracy skills
  • communication skills
  • information and communication technology (ICT) skills
  • interpersonal/teamwork skills
  • self-management and professional development skills
  • Subject-specific knowledge and understanding, expressed as what a graduate “will be able to”, in three areas:
    • “agriculture and horticulture”,
    • “the agricultural sciences”,
    • “food science and technology”.

    Both the subject-specific and the generic skills have descriptions for what is expected at three levels: “threshold”, “typical”, and “excellent”. While this is an interesting and reasonable structure, the details of the structure do differ from the NOSs in the same area.

    We have also to reckon with the fact that just about any of a tree’s smallest branches can in principle be extended to even more detailed and smaller ones by adding thinner twigs. It might be tempting to try this with the Tuning competences, as talk about the “principles of law”, and how they linked with other “knowledge”, begs the question of what principles we are talking about and indeed how they are linked. However, in practice this is unlikely, because the Tuning work is intended as a synthesis and reference point for diverse academic objectives, and typically every academic institution will structure their own version of these competences in their own different ways. Another way in which two similar trees may differ is the number of intermediate layers, together with the branching factor. One tree may have twenty “thinner” branches coming off a “thicker” one; another tree may cover the same twenty by first having four divisions, each with five sub-divisions. There is no right or wrong here, just variants.

    A simple way of representing many tree structures is to document the relationship between elements that are immediately larger and smaller, or broader and narrower. And recently, there seems to be a significant consensus building up that relationships from the SKOS Simple Knowledge Organization System are a good start, and may be the best known and most widely known relationships that fit. SKOS has the relationships “broader” and “narrower”: the broader competence, skill, or knowledge is the one that covers a set of narrower ones. The only thing to be careful about is that the SKOS terms come from the librarian’s BT and NT — that is, if we write “A broader B” it does not mean “A is broader than B”, but the opposite, that A is associated with a broader term, and that broader term is B. Thus B is a broader concept than A. Then, to use SKOS in the way it is designed to be used, we need identifiers for all the terms that might occur as “A” or “B” here. Each identifier would most reasonably be a URI, and needs to be clearly associated with its description.

    This general purpose structure of URIs and SKOS relations seems to be sufficient to represent the basic aspects of most aspects of the competence structures I have mentioned or referred to, beyond the concepts and definitions themselves. We will next look at more advanced considerations.