(11th in my logic of competence series)

Having discussed, defined, and mapped the principal features of the concepts of ability and competence, we are left with the challenge of working towards “the practical implementation of such competence structures” (ninth post) by looking at the “detailed structure and relationships of ability concepts and structures that contain several of them” (tenth post) and working towards a particular formalisation that represents those concepts adequately for the uses that are envisaged.

At this point, I’ll look back over the posts so far to collect what look like the principle requirements for implementing representations of competence in an interoperable way.

The first post in the series noted that the basis of “what is required” is logically the claim of, or the need for, an ability or competence. Thus an implementation should represent the analysis of “what is required” in terms of abilities. On reaching the sixth post, it was clear that the description of what is required can be formalised to an arbitrary degree, and analysed to an arbitrary granularity, so the formal structures used will need to be flexible rather than rigid.

The second post in the series briefly details the issue of transferability or commonality between different roles. Any formalisation should NOT try to answer questions of transferability, but rather provide a good basis for posing and answering those questions within their own domains.

The third post introduces the idea of abstractions in competence or ability definitions, and “common language between the outcomes of learning, education and training on the one hand, and occupational requirements on the other”. A common language is a language that is reused in different contexts. Particularly when concepts are used in different contexts, it is vital to identify them clearly, so that there is a minimum of ambiguity. Here is not the place to argue for the obvious choice for unambiguous identifier being the URI, but that is what I assume. A URI needs to be given to any ability or competence concept or framework that may plausibly need to be referred to across different contexts or applications. This obviously includes both the case from the second post of transferring between different occupational context, and the case from the third and later posts about what is being learned in education or training contexts being used in occupational ones.

The third post also started to look at some of the large body of UK National Occupational Standards (NOSs). One common sense requirement is that any common representation needs to relate to existing relevant materials. Doing this sets up the possibility of broad and fast adoption (politics and other factor being favourable, and with a fair wind) whereas failure to do this sets up the barrier of having to revise existing materials before adoption. Each NOS is clearly a hierarchically structured document, so a common representation must at least deal with simple hierarchical structures.

The fourth post on levels suggests that a simple hierarchy will often not be sufficient. Both claims and requirements need to be able to include levels, and the representation of levels must allow automatic inferences about higher and lower levels.

The fifth post proposes the requirement for a formal representation to cover the kinds of conditions cited in personal claims and job specifications, that go beyond and detail abstract definitions.

The sixth post starts to suggest some technology ideas for the formal structures, starting with SKOS.

The seventh post points out that decomposition is not the only way of analysing competence concepts. We also need the idea of style, variant, or approach to doing “what is required”. (Though this post did not finally resolve how variants, optionality and levels relate to each other.)

The eighth and ninth posts recognise the value in being able to represent equivalencies and comparisons, across different structures or frameworks as well as within them, and propose using the SKOS Mapping Properties for this purpose.

Listing these requirements in brief, we seem to have something like this:

1. represent competence concepts suitably for reuse
2. represent analysis of competence in terms of abilities
3. deal with levels helpfully
4. cover claims and occupational requirements
5. use SKOS as a basis
6. represent styles or approaches as well as decomposition
7. represent relations across different frameworks

Putting all my proposals for meeting these requirements here would make this post uncomfortably long, so instead I’ll break it down into more bite-sized chunks. (If I change my mind on how to structure the following posts, I’ll change it here as well, and in any case I’ll link from here to following posts when written.)

First, I’ll deal with how we can formally represent individual competence concepts and frameworks so that the structures contain existing materials, can work well together, and can be fully reused.

Next, I’ll put forward my developed ideas on how to represent the structural relationships between competence concepts, and tag on dealing with categories.

Later, I’ll deal properly with the tricky area of levels, for which up to now I have not come across any really convincing solutions.

I’ll do these all with the help of diagrams, representing not the conceptual connections of the previous post, but information modelling connections. This will come together in a big diagram.

I also want to compare and contrast with diagrams representing other past attempts to represent these things, but I haven’t yet decided whether to try to cover that bit by bit while first putting forward the ideas, or to do a big post that covers several alternatives.

After that, for real implementation, we’ll need to discuss the “binding” question — that is, the different ways of representing this emerging information model, particularly looking at XML, Atom, RDF triples, and XHTML+RDFa.

And I hope also to say a word about my great collaborators, the projects we have done or are doing together, and how this work relates to those projects.

At that point, I hope to be able to conclude the series, having outlined a fair solution to the practical representation of the logic of competence!

Now, on to the question of representing how definitions and structures relate to each other.