Structural relations for competence concepts

(13th in my logic of competence series)

My recent thoughts on how to represent the interplay between competence definitions and structures seem to be stimulating but probably not convincing enough. This post tries to clarify the issues more thoroughly, at the same time as introducing more proposals about the structural relationships themselves.

Clear explanation seems always to benefit from a good example. Let me introduce my example first of all. It is based on a real ability — the ability to make pizzas — but in the interests of being easy to follow, it is artificially simplified. It is unrealistic to expect anyone to define a structure for something that is so straightforward. But I hope it illustrates the points fairly clearly.

I’m imagining a British Society of Home and Amateur Pizza Makers (BSHAPM), dedicated to promoting pizza making competence at home, through various channels. (The Associazione Verace Pizza Napoletana does apparently exist, however, and organises training in pizza making, which does have some kind of syllabus, but it is not fully defined on their web site.) BSHAPM decides to create and publish a framework for pizza making competence, liberally licenced, that it can be referred to by schools, magazines, and cookery and recipe sites. A few BSHAPM members own traditional wood-fired pizza ovens which they occasionally share with other members. There are also some commercial pizza outlets that have an arrangement with the BSHAPM.

The BSHAPM framework is about their view of competence in making pizzas. In line with an “active verb” approach to defining skills, it is simply entitled “Make pizza”. The outline of the BSHAPM framework is here:

  • prepare pizza dough
    • with fresh yeast
    • with dried yeast
    • with non-yeast raising agents
  • form dough into a pizza base
    • by hand in the air
    • with a rolling pin on a work surface
  • prepare a pizza base sauce from available ingredients
  • select, prepare and arrange toppings according to eater’s needs and choices
  • prepare complete pizza for baking
  • bake pizza
    • in kitchen oven
    • in a traditional wood-fired oven
    • in a commercial pizza oven

The framework goes into more detail than that, which will not be needed here. It also specifies several knowledge items, both for the overall making pizza framework, and for the subsidiary abilities.

Clearly the ability detailed in the BSHAPM “make pizza” framework is a different ability to several other abilities that could also be called “make pizzas” — for instance, the idea that making pizzas involves going to a shop, buying ready-made pizzas, and putting them in the oven for an amount of time specified on the packaging.

As well as the BSHAPM framework, we could also imagine related structures or frameworks, for:

  • all food preparation
  • general baking
  • making bread
  • preparing dough for bread etc.

So, let’s start on what I hope can be common ground, clarifying the previous post, and referring to the pizza example as appropriate.

Point 1: Frameworks can often be seen as ability definitions. The BSHAPM concept of what it takes to “make pizza” represents an ability that people could potentially want to claim, provide evidence for, or (as employers) require from potential employees. It could be given a long description that explains all the aspects of making pizza, including the various subsidiary abilities. At the same time, it defines a way of analysing the ability to make pizza in terms of those subsidiary abilities. In this case, these are different aspects or presentations of the same concept.

Point 2: Each component concept definition may be used by itself. While it is unlikely that someone would want to evidence those subsidiary abilities, it is perfectly reasonable to suppose that they either could form part of a course curriculum, or could be items to check off in a computer-based system for someone to develop their own pizza-making skills. They are abilities in their own right. On the other hand, it is highly plausible that some other curriculum, or some other learning tracking system, might want not to represent the subsidiary abilities as separate items, particularly in cases where the overall competence claimed were at a higher level. In this case (though not generally) the subsidiary abilities are reasonably related to steps in the pizza making process, and we could imagine a pizza production line with the process at each stage focusing on just one subsidiary ability.

Point 3: The structure information can in principle be separated from the concept definitions. Each ability definition, including the main one of “make pizza” and each subsidiary one, can be defined in its own right and quoted separately. The “rest” of the framework in this case is simply documenting what is seen as part of what: the fact that preparing pizza dough is part of making pizza; baking the pizza is part of making pizza, etc., etc.

Point 4: The structure information by itself is not a competence concept, and does not look like a framework. One cannot claim, produce evidence for, nor require the structural links between concepts, but only items referred to by that structure information. It is stretching a point, probably beyond breakage, to call the structural information by itself a framework.

Point 5: Including a structured ability in a framework needs choice between whether to include only the self-standing concept or to include all the subsidiary definitions. To illustrate this, if one wanted to include “make pizza” into a more general framework for baking skills, there is the question of the level of granularity that is desired. If, for example, the subsidiary skills are regarded as too trivial to evidence, train, assess, etc., perhaps because it would be part of a higher level course, then “make pizza” by itself would suffice. It is clearly the same concept though, because it would be understood in the same way as it is with its subsidiary abilities separately defined. But if all the subsidiary concepts are wanted, it is in effect including a structure within a structure.

These initial points may be somewhat obscured by the fact that some frameworks are very broad — too broad to be mastered by any one person, or perhaps to broad to have any meaningful definition as a self-standing competence-related concept. Take the European Qualifications Framework (EQF), for example, that has been mentioned in previous posts (4; 10). We don’t think of EQF being a single concept. But that is fine, because the EQF doesn’t attempt to define abilities in themselves, just level characteristics of those abilities.

There are other large frameworks that might be seen as more borderline. Medicine and the health-related professions provide many examples of frameworks and structures. The UK General Medical Council (GMC) publishes Good Medical Practice (GMP), a very broad framework covering the breadth of being a medical practitioner. It could represent the structure of the GMC’s definition of what it is to “practice medicine well”, though that idea may take some getting used to. The question of how to include GMP in a broader framework will never practially arise, because it is already quite large enough to fill any professional life completely. (Ars longa, vita brevis…)

It is for the narrower ranges of ability, skill or competence that the cases for points 1 and 5 are clearest. This is why I have chosen a very narrow example, of making pizza. For this, we can reflect on two questions about representation, and the interplay between frameworks and self-standing concept definitions.

  • Question A: What would be a good representation of a structure to be included within a wider structure?
  • Question B: What difference is there between that and just the main self-standing concept being included?

So let’s try to elaborate and choose a method for Point 3 — separating self-standing concept definitions from structural information. Representing the self-standing concepts is relatively clear: they need separate identifiers so that they can be referred to separately, and reused in different structures. The question to answer first, before addressing A and B is how to represent the structure information.

  1. Option one is to strip out all the relations, and bundle them together separately from all the concept definitions. “Make pizza” at the broadest, and the other narrower abilities including “bake pizza”, would all be separate concepts; the “structure for” making pizza would be separately identified. The “make pizza” framework would then be the ensemble of concept definitions and structure.
  2. Option two is to give an identifier to the framework, where the framework consists of the concepts plus the structure information, and not give an identifier to the structure information by itself.

Let’s look again at this structural information with an eye on whether or not it could need an identifier. The structural information within the imagined BSAPHM framework for making pizza would contain the relations between the various ability concepts. There would be necessary part and optional part relations. A necessary part of making pizza the BSAPHM way is to make the dough, but how the dough is made has three options. Another necessary part is to form the pizza base, and that has two options. And so on.

So, perhaps now we are ready to compare the answers to the questions A and B asked above. To include one self-standing concept in another framework requires that the main concept is represented with its own identifier, because both an identifier for the framework, and an identifier for the structural information, would imply the inclusion of subsidiary abilities, and those are not wanted. To include the framework as a whole, on the other hand, there is a marked difference between options one and two. In option one, both the identifier for the main concept and the identifier for the structural information need to be associated with the broader concept, to indicate that the whole structure, not just the one self-standing concept, is included in the broader framework. Even if we still have the helpful duality of concept and structure, the picture looks something like this (representing option 1):


If we had to represent the concept and structure entirely separately, the implementation would surely look still worse.

Moving forward, option two looks a lot neater. If the framework URI is clearly linked (though one structural relation) to the main concept definition, there is no need for extra optional URIs in the relations. It’s worth saying at this point that, just as with so many computational concepts, it is possible to do it in many ways, but it is the one that makes most intuitive sense, and is easiest to work with, that is likely to be the one chosen. So here is my preferred solution (representing option 2):


To propose a little more detail here: the types of relationship could cover which concepts are defined within the framework, and specifying the main concept, as well as the general broader and narrower relationships, in two variants — necessaryPart and optionalPart. (I’ve now added more detailed justification for the value of this distinction in post 15 in this series.)

[The following paragraph was altered after reconsideration, 2011-05-26]

One of the practical considerations for implementation is, what has to happen when something that is likely to change, changes? What can and cannot change independently? It seems clear (to me at least) that if a framework changes substantially, so that it no longer expresses the same ability, the main concept expressed by that framework must also change. Evidence for a “make pizza” concept whose structure does not include preparing dough doesn’t provide full evidence for the BSHAPM concept. It is a different concept. On the other hand, if the long description of the concept remains the same, it is possible to have a different structure expressing the same concept. One obvious way in which this is possible is that one structure could for BSHAPM pizza making could include just the abilities listed above, while a different structure for exactly the same ability concept could include a further layer of detail, for example spelling out the subsidiary abilities needed to make a pizza base in the air without a rolling pin. (It looks tricky: I’ve seen it once but never tried it!) Nothing has actually changed, but it is more detailed with more of the subsidiary abilities made explicit.

These arrangements still support the main idea, valuable for reuse, that the concept definitions can remain the same even if they are combined differently in a different framework.

There are two other features that, for me, reinforce the desirability of option 2 over option 1. They are, first, that various metadata can be helpfully shared, and second, that a range of subsidiary competence concepts can be included in a framework. Explanation follows here.

[The following paragraph was altered after reconsideration, 2011-06-08]

First, I am now saying that you can’t change a framework structure substantially without changing the nature of the main competence concept that stands for competence in the framework abilities together as one. The structure or framework would probably be called be something like “the … framework” where the title of the main concept goes in place of the dots. The two titles are not truly independent, but need differentiation, because of the different usage (and indeed meaning) of the competence structure and the competence concept.

Second, if we have an identified framework including a main concept definition as in option 2, there seems no reason why it should not, in the same way, include all the other subsidiary definitions that are defined within the framework. This seems to me to capture very well the common-sense idea that the framework is the collection of things defined within it, plus their relationships. Concepts imported from elsewhere would be clearly visible. In contrast, if the structural information alone is highlighted as in option 1, there is no obvious way of telling, without an extra mechanism, which of the URIs used in the structure are native to this framework, and which are imported foreign ones.

There are probably more reasons for favouring option 2 over option 1 that I have not thought of for now — if on the other hand you can think of any arguments pointing the other way, please preferably comment below.

If I had more time to write this, it would probably be more coherent and persuasive. Which reminds me, I’m open to offers of collaboration for turning these ideas into more tightly argued and defended cases for publication somewhere.

But there is more to finish off — I would like to cover the rest of the relationships that I see as important in the practical as well as logical representation of competence.

However, after writing the original version of this post, I have had some very useful discussions with others involved in this area, reflections on which are given in the next post.

Representing the interplay between competence definitions and structures

(12th in my logic of competence series, heavily edited 2011-06-17)

One of the keys to a fuller understanding the logic of competence is the interplay between, on the one hand, the individual definition of an ability or competence concept, and on the other hand, a framework or structure containing several related definitions. Implementing a logically sound representation of competence concepts depends on this fuller understanding, and this was one of the requirements presented in the previous post.

A framework by its very nature “includes” (in some sense to be better understood later) several concept definitions. Equally, when one analyses any competence concept, it is necessarily in terms of other concepts at least related to competence. There would seem to be little difference in principle between these more and less extensive structures.

When we consider a small structure it is easier to see that the small structures usually double as a concepts in their own right. To illustrate this, let’s consider UK National Occupational Standards (NOSs) again. Back in post number 3 we met some LANTRA standards, where an example of a unit, within the general topic of “Production Horticulture”, is the one with the name “Set out and establish crops”. In this unit, there is a general description — which is a description or definition of the competence concept, not a definition of its components — and then lists of “what you must be able to do” and “what you must know and understand”. The ability items are probably not the kinds of things you would want to claim separately (there are too many of them), but nevertheless they could easily be used as in checklists both for learning, and for assessment. My guess is that a claim of competence would be much more likely to reference the unit title in this case.

From this it does appear that a NOS unit simultaneously defines a competence concept definition, and also gives structure to that concept.

It is when you consider the use of these competence-related structures that this point reveals its real significance. Perhaps the most important use of these structures by individuals is in their learning, education and training, and in the assessment of what they have learned. In learning a skill or competence, or learning what is required to fulfill an occupational role, the learner has many reasons to have some kind of checklist with which to monitor and measure progress. What exactly appears on that checklist, and how granular it is, makes a lot of difference to a learner. There can easily be too much or too little. Too few items on the list would mean that each item covers a lot of ground, and it may not be clear how they should assess their own ability in that area. To take the LANTRA example above, it is not clear to a learner what “Set out and establish crops” involves, and learners may have different ideas. The evidence a learner brings up may not satisfy an employer. At the other extreme, I really wouldn’t want a system to expect me to produce separate evidence for whether I can start a tractor engine, find the gears, and steer the machine. That would be onerous and practically useless.

Structures for practical use in ICT tools need, therefore, to be clear about the what is included as a separate competence-related definition within the structure, and what is not included, or included only as part of the description of a wider definition.

The “Set out and establish crops” LANTRA unit does have a clear structure, and the smallest parts of that structure are the individual ability and knowledge items — what someone is expected to be “able to do”, and to “know and understand”. And let us suppose that we formalise that unit in that way, so that an ICT learning or assessment support tool allowed learners to check off or provide evidence for the separate items — e.g. that they could “ensure the growing medium is in a suitable condition for planting” and that they knew and understood the “methods of preparing growing media for planting relevant to the enterprise”.

Then, suppose we wanted to include this unit in another structure or framework. Would we want, perhaps, just one “box” to be ticked only for the unit title, “Set out and establish crops”; or would we want two boxes corresponding to the elements of the unit, “Set out crops in growing medium” and “Establish crops in growing medium”; or would we rather have all the ability and knowledge items as separate boxes? None of these options are inherently implausible.

To put this in a different way: when we want to include one competence-related structure within another one, how do we say whether we just want it as a single item, or whether we are including all the structure that comes with it? The very fact that this is a meaningful question relies on the dual nature of a definition, as either a “stand-alone” concept, or structure.

The solution I propose here is that we have two identifiers, one for the concept definition itself, and one for the structure definition that includes the concept. I understand these as closely related. But the description of the structure would perhaps more naturally talk about what it is used for, and wouldn’t be the kind of thing that you can claim, while the description of the concept would indeed describe something that one could claim or require. The structure is structured, whereas the definition of the concept by itself is not, and the structure relies on definitions of subsidiary concepts, that are the parts of the whole original concept.

I illustrated a change of wording in the eighth post, raising, but not answering the question of whether the concept remained unchanged across the changed wording of the definition.

Let’s look at this from another angle. If you author a framework or structure, in doing that you are at the same time authoring at least one competence-related concept definition, and there may be one main concept for that structure or framework. You will often be authoring other subsidiary definitions, which are parts of your structure. You may also include, in your structure or framework, definitions authored by others, or at another time. Indeed, it is possible that all the other components come from elsewhere, in which case you will be authoring only the minimal one concept definition.

One more question that I hope will clarify things still further. What is the title of a structure? The LANTRA examples illustrate that there may be no separate title of a structure, from the title of the main concept definition contained in it. But really, and properly, the title of the structure should be something like “the structure for <this competence concept>”.

Contrast this with the subsidiary concept definitions given in the structure. Their titles and descriptions clearly must be different. They may be defined at the same time as the structure, or they may have been defined previously, and be being reused by the structure.

Exactly how all this is represented is a matter for the “binding” technology adopted. Representing in terms of an XML schema will look quite different from RDF triples, or XHTML with RDFa. I’ll deal with those matters in a later post. But, however implemented, I do think we have the beginnings of a list of information model features that are necessary (or at least highly desirable) for representing this interplay between competence definitions and structures. (I will here assume that identifiers are URIs.)

  1. The structure (or framework) has its own URI.
  2. The structure often has a “main” concept that represents the structure taken as a separate concept.
  3. The structure cannot be represented without referring to the concept definitions that are structured by it.
  4. Each concept definition, including the main concept and subsidiary concepts, has its own URI.

I’ve tried to represent this in a small diagram. See what you think…
(note that the colours bear no relation to colours in my other concept maps)


Of course, as well as the URIs, titles and descriptions, there is much more from structures or frameworks to represent, particularly about the relations between the concepts. So it is to the practical implementation of this that I turn next.

Requirements for implementing the logic of competence

(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.